Publicado el Dejar un comentario

Vulnerabilidad en router Huawei HG8245H de TotalPlay

Me he animado a elaborar este reporte de vulnerabilidad en router Huawei HG8245H de TotalPlay debido a que en días pasados, unos amigos resultaron víctimas de un fraude bancario por Internet debido a esta “falla” en el servicio que te voy a documentar. Pero primero, veamos algunos conceptos:

¿Qué es el Phishing?

El Phishing, es el conjunto de “técnicas” o “prácticas” basadas en el engaño a una víctima ganándose su confianza, haciéndose pasar por una persona, empresa o servicio de confianza (suplantación de identidad de tercero de confianza), para manipularla y hacer que realice acciones que no debería realizar (por ejemplo revelar información confidencial o hacer click en un enlace).

Para realizar el engaño, habitualmente hace uso de la “ingeniería social” explotando los “instintos sociales” de la gente y su “familiaridad” con actividades rutinarias que realiza por costumbre, como puede ser el ayudar o tratar de ser eficiente.

No obstante lo anterior, a veces también hace uso de procedimientos informáticos que aprovechan vulnerabilidades de software o hardware, lo cual implica conocimientos técnicos más complejos.

En casi todos los casos, el objetivo del Phishing es robar información pero, en otros, el propósito es instalar malware, sabotear sistemas o robar dinero a través de fraudes más organizados.

¿Cuál es el problema con el router Huawei HG8245H de TotalPlay?

Básicamente, te he de contar que, la “Empresa “, contrató un servicio de Internet Empresarial de TotalPlay 200, para lo cual les fue proporcionado un router Huawei HG8245H.

router Huawei HG8245H de TotalPlay

Este dispositivo, por defecto, venía con el puerto 23 habilitado (lo descubrimos después); en este contexto, una necesidad de la organización es la de permitir conexiones en el puerto 80 para dar “salida” a un servidor Web. Así, tanto el puerto 23 como el 80 están “abiertos”.

Ahora bien, en esta organización, se comenzaron a presentar redireccionamientos extraños de nombres de dominio de instituciones bancarias, mostrando de manera inicial un mensaje de error, certificados SSL inválidos, y necesidad de “realizar acciones adicionales” y permisos en el navegador para poder “visitar” el sitio web deseado, como por ejemplo, “aceptar” ir a la “Configuración avanzada” y “permitir” alguna excepción o riesgo de uso del certificado SSL para “conectar” con la institución bancaria.

En este sentido, si “aceptamos” continuar bajo nuestro propio riesgo, habremos abierto la posibilidad de que el sitio original de nuestra institución bancaria, sea “resuelta” en un servidor apócrifo que contiene una página clonada de mi banco, cuyo principal objetivo será el obtener claves, números de tarjeta, tokens, información personal, etc.

Si observas detenidamente la URL de mi captura de pantalla, podrás observar que la URL de la institución bancaria BBVA.MX ha sido “redireccionada” indebidamente a otro nombre de dominio: el sitio fraudulento, Phishing a la vista.

Inclusive, te “presenta” un certificado de seguridad SSL para darte la confianza de que estás navegando en un entorno “segura” aprovechando las firmas de Let´s Encrypt, un estupendo servicio gratuito que ayuda a los desarrolladores o administradores de sistemas a fortalecer la entrega de servicios web cifrados para proveer a nuestros usuarios de un cierto nivel de protección en la red; pero que en este caso, es utilizado maliciosamente para “dar la impresión” de que estamos en un sitio seguro. En sentido estricto, la conexión estará cifrada pero, el sitio web en cuestión tiene una motivación: robarte tus datos. Aquí puedes ver un certificado SSL de una URL fraudulenta o de Phishing…

…y aquí puede ver un certificado correctamente autenticado por una autoridad certificadora de una institución bancaria acreditada.

¿Por qué tiene este redireccionamiento mi router Huawei HG8245H de TotalPlay?

Si eres un usuario no técnico, debes saber que cualquier dispositivo que sirva para “proveerte” de Internet en tu oficina o domicilio, cuenta con un panel de administración para realizar configuraciones adicionales.

En este sentido, el router Huawei HG8245H de TotalPlay, una vez que te hayas conectado de manera alámbrica o inalámbrica al mismo, puede administrarse accediendo a la IP 192.168.100.1 desde tu navegador.

Un primer problema es que, de fábrica, viene configurado para su acceso con los siguientes datos:

  • Usuario: root
  • Password: admin

Así, empleando estos datos, alguien dentro de tu red podría “aprovecharse” del dispositivo y realizar configuraciones indebidas. Aquí, puedes ver una captura de pantalla del panel de administración del router.

Una buena práctica para “dificultar” el acceso no autorizado al dispositivo es cambiar la contraseña de administración. Esto puede hacerse fácilmente accediendo a la pestaña “System Tools” y opción “Modify Login Password” para cambiar la contraseña.

En sentido estricto, si no cambias la contraseña de administración con la cual viene el router de fábrica, tienes una grave vulnerabilidad ahí que puede explotar, teóricamente, un usuario mal intencionado que esté conectado a tu red interna.

No obstante lo anterior, me ha pasado que, a pesar de que cambie la contraseña de acceso al dispositivo, inexplicablemente es vulnerado en sus configuraciones. Aquí, tengo mis sospechas sobre el puerto 23 que permite conexiones mediante Telnet que me ha dejado abierto TotalPlay por razones que desconozco.

Además, estas sospechas sobre el puerto 23 se incrementan en el sentido de que, revisando registros de acceso al panel de administración mediante su portal Web, no muestra ninguna evidencia de acceso no autorizado a través del mismo, pero sí intentos recurrentes de acceso al dispositivo.

La manipulación de nombres de dominio mediante configuración DNS en router Huawei HG8245H de TotalPlay

Y aquí llegamos al punto: el atacante malicioso (que me da la impresión, puede acceder desde la red interna de TotalPlay o bien, de mi propia red interna mediante algún equipo infectado con malware), “modifica” y “redirecciona” los destinos de “resolución” de un nombre de dominio, suplantando los registros DNS originales por otros que sin ningún inconveniente pueden ser “resueltos” mediante redireccionamiento en un servidor que haya configurado e instalado para tal propósito. Te explico:

https://bbva.mx es el sitio web de un banco español que tiene operaciones en México; haciendo un ping simple desde una red no comprometida, está “apuntado” a la IP 23.3.212.126 para su correcto funcionamiento.

Sin embargo, nuestro atacante malicioso y mal intencionado, implementa configuraciones como estas para “apoderarse” de nuestra conexión y llevarnos a un sitio web clonado de esta institución bancaria. El módem ha sido intervenido para que el dominio BBVA.MX sea “resuelto” en una IP distinta a la IP legal (23.3.212.126) para robar nuestros datos e información bancaria.

vulnerabilidad en router Huawei HG8245H

Como puedes observar en la captura de pantalla, los atacantes, han configurado la redirección de múltiples dominios de diversas instituciones bancarias para ser “resueltos” en servidores y dominios apócrifos, por ejemplo, aquí podrás ver una relación de sitios web de Phishing que he encontrado, y que están preparados para hacerse pasar por un banco y pedirte datos personales para robarte tu dinero:

¿Cómo te roban tus datos bancarios mediante técnicas de Phishing y vulnerabilidad en router Huawei HG8245H de TotalPlay?

Con la información que te he mostrado, y considerando un escenario en el que…

  1. Tu router está intervenido y configurado con estos redireccionamientos.
  2. Intentaste entrar a tu banco y te mostró el navegador una alerta a la cual, diste tu autorización de que “aceptas el riesgo” y;
  3. Te encuentras en un sitio web clonado (Phishing) de la lista anterior (pero puede haber muchos otros eh)…

…los maleantes, han conseguido una primera fase de su objetivo: ganar tu confianza en su sitio web. ¿Qué ocurrirá a continuación?

Básicamente, te encontrarás con algo como esto, siendo BBVA el caso de ejemplo de sitio web de phishing o clonado:

Te pedirán tu número de tarjeta de bancaria…
Te pedirán tu token de acceso (clave generada en tu app)…

Hasta este punto, todo parecerá “normal” ya que son los datos básicos que generalmente una institución bancaria te pide para la banca en línea. Sin embargo, en las siguientes imágenes, los atacantes maliciosos te comenzarán a pedir información personal que a su vez, ellos podrán utilizar para ingresar a tu banca en línea y tomar el control de tu dinero:

Aquí, han creado un formulario en el cual te piden, “para validar”, datos de tu tarjeta bancaria y de registro de usuario.

Cuando “envías tus datos para validar”, sean estos válidos o inválidos, te aparecerá una leyenda de “Datos incorrectos”; el objetivo de esto, es el de “engancharte” con la realización de múltiples intentos para que consigas tu objetivo (entrar a tu banca en línea) pero, explotando esta necesidad tuya “proporcionándoles” el mayor número de tokens o confirmación de datos bancarios posibles (una vez que “diste tus datos bancarios”, entre más “tokens” proveas, es para ellos mejor) a través de su sitio web clonado o de phishing que para tal propósito han creado.
Aquí, te vuelven a pedir que ingreses tu token en un “nuevo intento” por haber ingresado “datos incorrectos” a “tu banco” (sitio web de phishing o clonado)… y así será sucesivamente hasta que te canses.

Un proceso similar al anterior ocurre con otros bancos, en los que realizan la clonación del mismo para implementar esos sitios web de phishing:

¿Cómo puedo protegerme del fraude bancario mediante esta técnica de phishing en router Huawei HG8245H de TotalPlay?

Tanto si eres usuario doméstico como administrador de red de una organización, lo principal es que:

1.- Resetees completeamente tu dispositivo a sus valores de fábrica y modifiques la contraseña de acceso del mismo, sobre todo si no puedes acceder a su panel de administración mediante la URL 192.168.100.1 con sus valores por defecto (usuario: root, pasword: admin) ya que, es muy probable que alguien te los haya cambiado.

Debes recordar que este router, solo permite cambiar contraseñas y no tiene forma de que se modifiquen sus nombres de usuario.

2.- Te asegures que tu dispositivo no tiene el puerto 23 abierto (si así te lo entregó el técnico de TotalPlay, me queda aún más la duda de si no es que hay personal dentro de la empresa entregando dispositivos configurados para ser vulnerados). Puedes realizar una prueba rápida así:

a) Investiga cuál es la IP pública de tu red; para ello, ingresa al sitio https://myip.es/, por ejemplo:

b) Una vez que tengas tu IP, ingresa a http://www.t1shopper.com/tools/port-scan/ y realicemos un escaneo rápido de puertos abiertos a tu dispositivo, no sin antes seleccionar “check all” para que se realicen pruebas en los puertos más comunes.

Si te aparece el puerto 23 abierto, es muy probable que tu dispositivo esté intervenido y vulnerable; en los resultados del escaneo, te estaría apareciendo algo así:

3.- Ya que tengas tu router Huawei HG8245H reseteado y con contraseña modificada, accede ahora al panel de control e ingresa al apartado “Forward Rules” y “Port Mapping Configuration”. A continuación crea una nueva regla (en “Mapping Name” ponle el nombre que desees) con los siguientes valores y haz clic en “Apply”:

Con lo anterior, ¡habrás aplicado una capa de seguridad a tu dispositivo para mitigar la vulnerabilidad en router Huawei HG8245H de TotalPlay.

Recomendaciones finales

Sin importar si eres un usuario doméstico o administrador de redes, espero que este artículo te haya servido.

En mi caso, una práctica que tengo por una Internet segura es el de notificar a ISPs, Google, Mozilla sobre la existencia de dominios con actividad maliciosa. No obstante, me he encontrado con la indiferencia de TotalPlay para resolver este tema (insisto nuevamente, me queda la impresión de que los “ataques” vienen de dentro de la red de ellos y no tanto de la red pública) así como también, el total desinterés de los bancos para responder a los llamados y dar protección a sus usuarios.

Por ello, te invito a que pongas atención en las siguientes recomendaciones.

  • Denuncia las URLs maliciosas siempre; en tu navegador Google Chrome haz clic en los “3 puntitos” de opciones adicionales, selecciona el menú “ayuda” y envía tu reporte con comentarios (importante que pongas “sitio de phishing”) haciend clic en “enviar reporte”; en el navegador Mozilla Firefox, haz clic en las “3 rayitas” de opciones adicionales, haz clic en el menú “ayuda” y envía también tu reporte haciendo clic en la opción “Reportar sitio fraudulento…”
  • Ten la buena práctica y costumbre de siempre verificar la validez de las URLs que visitas.
  • Enseña a tus usuarios y compañeros a navegar de manera segura.
  • Cambia tu router por otro mejor; los TP-Link Archer AX50, es un estupendísimo dispositivo que tiene una solución embebida para proteger a todos los usuarios de tu red de virus y bloquear URLs fraudulentas o de phishing. Si instalas Internet de TotalPlay, no te fíes de su router: compra y configúrate el Archer AX50 para que tengas mayor confianza y seguridad en tu red, sobre todo si vas a utilizar tu conexión para dar internet a tus empleados, cubrir tus oficinas, realizar tus operaciones bancarias, etc. Invierte en tecnología, en infraestructura, en asesoría de los expertos.
Publicado el Dejar un comentario

Configurar una tarjeta de red con WPA desde la línea de comandos en Ubuntu

configurar una tarjeta de red con WPA desde la línea de comandos

En mi oficina, tengo una vieja laptop a la cual, el monitor de cuando en cuando deja de funcionar sin forma de volver a encenderlo nuevamente. Con ello en consideración, decidí tomar esta laptop para configurarme un modesto servidor conUbuntu Server 14.04 LTS en el cual tengo habilitado Apache, PHP y MySQL principalmente con la cual te mostraré cómo conigurar una tarjeta de red con WPA desde la línea de comandos en Ubuntu.

Es pertinente comentar en este que punto que para el presente tutorial, procedí a realizar una instalación limpia de Ubuntu Server 14.04, configuré mi tarjeta de red, particiones y demás, pero al concluir el proceso de reinicio posterior a la instalación.

Así, para lograr que Ubuntu “inicie” y se “conecte” automáticamente a una red WPA, tenemos que seguir los siguientes pasos desde la consola o línea de comandos:

1.- Averiguamos en primer lugar el nombre de nuestra interface de red inalámbrica (generalmente es wlan0):

iwconfig

2.- Creamos el archivo de configuración del demonio de administración de redes wpa_supplicant…

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

…y guardamos dentro del mismo los siguientes valores:

ctrl_interface=/var/run/wpa_supplicant
network={
ssid="NOMBRE-DE-RED-WIFI"
key_mgmt=WPA-PSK
psk="CONTRASEÑA-WIFI"
}

3.- Ahora, iniciamos el demonio wpa_supplicant mediante el siguiente comando:

sudo wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -B

4.- “Levantamos” nuestra tarjeta de red…

sudo ifconfig wlan0 up

5.- Pedimos ahora una dirección IP al servidor DHCP activo:

sudo dhclient wlan0

6.- Con ello, si hacemos un ping a google.com, deberías de obtener ya una respuesta. Pero bien, para que nuestra configuración se cargue en cada reinicio, abrimos el archivo /etc/network/interfaces…

sudo nano /etc/network/interfaces

…y nos aseguramos de añadir lo siguiente:

auto wlan0
iface wlan0 inet dhcp
wpa-ssid NOMBRE-DE-RED-WIFI
wpa-psk CONTRASEÑA-WIFI

7.- Para comprobar que el demonio wpa_supplicant se iniciará automáticamente en cada inicio del sistema, ejecutamos los siguientes comandos:

sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start

¡Y es todo!

Si deseas profundizar mucho más en el tema u obtener información para realizar un proceso similar para redes WEP, te recomiendo hacer clic en este enlace, el cual te llevará a un excelentísimo artículo que habla con gran detalle sobre este proceso.

Publicado el Dejar un comentario

Bloquear accesos por país con Firewall CSF

Bloquear accesos por país con Firewall CSF

Para todos aquellos que en algún momento tengan la necesidad de desarrollar actividades de administración de un servidor Web bajo GNU/Linux, descubrirán que Internet es un entorno más que propicio tanto para la colaboración o distribución de contenidos, como también, para prácticas maliciosas o ataques informáticos por lo que seguramente te resultará de gran utilidad el aprender a bloquear accesos por país con firewall CSF.

En este sentido, les comento que en mi práctica profesional, y concretamente, para el caso de una tienda en línea administrada con Magento, comencé a notar una baja en el performance impresionante, al punto tal en que las peticiones al servidor, se resolvían muy lentamente.

En este contexto, una solución “rápida” y “lógica” era incrementar los recursos del VPS contratado (más memoria RAM, más procesador), con el respectivo costo asociado.

Al revisar los logs de Apache (siempre es una buena práctica, algo tediosa) y las estadísticas del sitio en mi panel de control (con AW Stats o Webanalizer) y las visitas de Google Analytics, descubrí que tenía visitas en varias horas del día, y con distinta intensidad, del robot del buscador Chino llamado Baidu.

Con esta información en consideración, mi primer “movimiento” lógico, fue deshabilitar la indexación del agente/bot Baidu en el home de mi servidor, pero, el problema persistía: Baidu maneja diversos agentes (de contenidos, de imágenes, de video, etc.) para indexar un sitio, y para serles francos, aún y cuando Baidu tiene documentadas las medidas para el manejo de sus bots mediante el archivo robots.txt (puedes consultarlas aquí: http://help.baidu.com/question?prod_en=master&class=498&id=1000973), me dio la impresión de que sus bots no respetaban las instrucciones contenidas en el mismo, por lo cual, teniendo en consideración que el público de la tienda en línea era solo mexicano, procedí a realizar un bloqueo mediante reglas de un Firewall basado en software, inicialmente a China, con posibilidades de extenderlo a todo el mundo y permitir solo IP´s de México y Estados Unidos. Es importante destacar que Baidu, tiene una “página” en la cual uno puede “retroalimentar” y reportar incidentes; la liga es: http://webmaster.baidu.com/feedback/index. Aquí puedes encontrar más información sobre el “bloqueo” a Baidu Spider mediante el archivo robots.txt: http://www.baidu.com/search/robots_english.html

Consideraciones

Este “truco” te funcionará si tienes una distribución Linux en la cual tengas acceso como root o usuario con privilegios. Si tienes un VPS, asegúrate que si realizas por accidente un “bloqueo” a la IP desde la cual te conectas, podrás acceder nuevamente mediante una terminal o consola Web que te ofrezca tu propio proveedor.

Primeros pasos

CSF (ConfigServer Security & Firewall), es un poderoso conjunto de scripts que nos permiten disponer reglas de iptables para constituir un Firewall SPI (Stateful Packet Inspection) basado en software, con detector de intrusiones y seguridad en aplicaciones para servidores Linux.

Si actualmente tienes reglas de IPtables aplicadas en tu server, es muy probable que vayas a tener conflicto con las mismas, por lo cual, es muy probable que decidas qué solución de Firewall pretendes usar, o bien, analizar si CSF puede hacer por tí lo que actualmente estás haciendo con otra solución. Desde mi punto de vista personal, CSF es uno de los Firewalls para servidores Linux más potentes, transparentes y sencillos de usar que he visto.

Puedes conocer más a fondo las características de CSF visitando este link: http://configserver.com/cp/csf.html

Para este tutorial, estaré trabajando sobre Ubuntu Server 14.04.01 de 64 Bits.

De igual manera, la documentación oficial para la instalación de CSF la puedes encontrar aquí: http://download.configserver.com/csf/install.txt

Comentado lo anterior, primero vamos “actualizar” un poco algunas dependencias y paquetes de Perl requeridos:

sudo apt-get install libwww-perl liblwp-protocol-https-perl

Posteriormente, vamos a proceder a descargar y descomprimir el conjunto de scripts de CSF mediante el siguiente comando:

cd /usr/src
sudo wget https://download.configserver.com/csf.tgz
sudo tar -xzf csf.tgz

Ahora, procedemos a realizar la ejecución del script de instalación de CSF:

cd csf
sudo sh install.sh

Si no ha habido mayores problemas, podrás leer en tu pantalla algo como esto:

TCP ports currently listening for incoming connections:
     22

UDP ports currently listening for incoming connections:
     68,45861

Note: The port details above are for information only, csf hasn't been auto-configured.

Don't forget to:
     1. Configure the following options in the csf configuration to suite your server: TCP_*, UDP_*
     2. Restart csf and lfd
     3. Set TESTING to 0 once you're happy with the firewall, lfd will not run until you do so
     «lfd.sh» -> «/etc/init.d/lfd»
     «csf.sh» -> «/etc/init.d/csf»
     el modo de «/etc/init.d/lfd» permanece como 0755 (rwxr-xr-x)
     el modo de «/etc/init.d/csf» permanece como 0755 (rwxr-xr-x)
     Removing any system startup links for /etc/init.d/lfd ...
     Removing any system startup links for /etc/init.d/csf ...
     Adding system startup for /etc/init.d/lfd ...
     /etc/rc0.d/K20lfd -> ../init.d/lfd
     /etc/rc1.d/K20lfd -> ../init.d/lfd
     /etc/rc6.d/K20lfd -> ../init.d/lfd
     /etc/rc2.d/S80lfd -> ../init.d/lfd
     /etc/rc3.d/S80lfd -> ../init.d/lfd
     /etc/rc4.d/S80lfd -> ../init.d/lfd
     /etc/rc5.d/S80lfd -> ../init.d/lfd
     Adding system startup for /etc/init.d/csf ...
     /etc/rc0.d/K80csf -> ../init.d/csf
     /etc/rc1.d/K80csf -> ../init.d/csf
     /etc/rc6.d/K80csf -> ../init.d/csf
     /etc/rc2.d/S20csf -> ../init.d/csf
     /etc/rc3.d/S20csf -> ../init.d/csf
     /etc/rc4.d/S20csf -> ../init.d/csf
     /etc/rc5.d/S20csf -> ../init.d/csf
     «/etc/csf/csfwebmin.tgz» -> «/usr/local/csf/csfwebmin.tgz»

Installation Completed

Lo que debemos saber

CSF es una colección de scripts muy potente, que en un momento determinado, puede inclusive “impedirnos” la conexión remota al servidor si no tenemos muy claro lo que hacemos.

En este sentido, la ruta para la edición de su archivo de configuración, es:

/etc/csf/csf.conf

Dentro del mismo, tenemos 2 líneas que son muy interesantes:

  1. TESTING = “1” – Si está activida esta regla así, es porque tu Firewall está en “modo de prueba” con lo cual, en función del valor asignado en el siguiente punto (testing_interval), pasado ese tiempo, te “borrará” todas las reglas de Firewall con el propósito de “regresar” a la normalidad. En otro caso, si has quedado conforme con la configuración de Firewall, puedes ponerle el valor de “0”, con lo cual, quedará aplicado este sistema.
  2. TESTING_INTERVAL = “5” – Si las reglas de Firewall están en modo de prueba (testing), pasado número de minutos, se “limpiarán” del sistema, volviendo todo a la normalidad.

Bloquear accesos por país con firewall CSF y asignación de permisos de conexiones por país

Particularmente, CSF utiliza los 2 caracteres de país del código ISO de países CIDR (Classless Inter-Domain Routing – enrutamiento entre dominios sin clases) mediante el cual, se “clasifican” los rangos de direcciones IP de cada país. Como comenta CSF en el archivo de configuración, esta lista no es 100% segura ya que algunos ISPs, usan designaciones de IP para sus clientes mediante criterios no geográficos, lo cual dificulta su ubicación.

Por otra parte, la creación de reglas asociadas a grandes rangos de direcciones IP, pueden representar una disminución en el performance del servidor, con lo cual, no es muy recomendado para servidores VPS; aunque en mi caso, lo he usado en VPS de 1 GB de RAM y me fue muy bien, inclusive, me ayudó con tráfico indeseado.

Con ello en consideración, CSF se apoya en los 2 caracteres de país para la asignación en las reglas de Firewall, a partir de los bloques CIDR administrados por Maxmind GeoLite Country, el cual puedes consultar aquí: http://dev.maxmind.com/geoip/legacy/geolite/ (te sugerimos descargar el archivos CSV disponible para crear tus reglas con mayor seguridad y certeza).

Ahora bien, ¿qué haré? Permitiré el tráfico a México y Estados Unidos, y bloquearé al resto del mundo. Para ello, deberemos editar el archivo de configuración de CSF:

sudo nano /etc/csf/csf.conf

Ahora, buscamos las líneas:

CC_DENY = ""
CC_ALLOW = ""

Y nos aseguramos que queden algo así como:

CC_DENY = "AU,CN,JP,TH,IN,MY,KR,SG,HK,TW,PH,VN,RU,FR,EU,DE,IL,SE,IT,NL,GR,ES,AT,GB,BE,AE,KZ,PT,SA,DK,IR,NO,CA,SY,UA,CY,CZ,CH,IQ,TR,RO,BZ,PA,BR,CL,AR,CO,PL,LB,GE,AZ,A2,PS,LT,OM,SK,RS,FI,IS,HU,BG,SI,MD,MK,LI,JE,HR,BA,PY,EE,LV,JO,A1,KG,RE,IE,IM,LY,LU,AM,VG,YE,BY,GI,QA,KW,GP,MQ,GF,ZA,EG,ID,PK,DO,GU,VI,PR,MN,NZ,NP,PG,AP,CR,PE,NG,VE,BS,MA,SC,BB,KE,BN,BH,AW,LC,BD,TK,KH,MO,MV,AF,NC,FJ,WF,AL,UZ,ME,KP,VA,AQ,BM,CW,EC,KN,WS,GG,MT,TJ,ZW,LR,GH,TZ,ZM,MG,AO,NA,CI,SD,CM,MW,MU,GA,ML,BJ,TD,BW,CV,RW,CG,UG,MZ,GM,LS,DZ,GN,CD,SZ,BF,SL,SO,NE,CF,TG,BI,GQ,SS,SN,MR,DJ,KM,TN,YT,LA,MM,LK,NR,VU,BT,FM,PF,TL,TO,ER,ET,TM,GL,KY,JM,GT,MH,MC,AI,GD,MS,TC,AG,TV,SB,BO,SR,CK,NU,TF,NF,PN,SM,AX,FO,SJ,CC,GS,UM,SX,GW,MF,VC,PM,BL,DM,ST,FK,MP,BQ,AS,KI,PW,GY,HN,NI,SV,AD,HT,TT,UY,CU,SH,CX,IO"
CC_ALLOW = "MX,US"

Ahora, guardamos el archivo, y reiniciamos el CSF:

sudo csf -r

Y revisamos las reglas aplicadas:

sudo iptables -L -n

Pasos finales

Por otra parte, con el objetivo de que nuestro Firewall tome acciones a partir de “falsos positivos” o “información confusa” proporcionada por los registros del sistema (syslog/rsyslog), en el archivo /etc/csf/csf.conf, debemos cambiar esto:

# 0 = Allow those options listed above to be used and configured
# 1 = Disable all the options listed above and prevent them from being used
# 2 = Disable only alerts about this feature and do nothing else
# 3 = Restrict syslog/rsyslog access to RESTRICT_SYSLOG_GROUP ** RECOMMENDED **
RESTRICT_SYSLOG = "0"

Por esto:

# 0 = Allow those options listed above to be used and configured
# 1 = Disable all the options listed above and prevent them from being used
# 2 = Disable only alerts about this feature and do nothing else
# 3 = Restrict syslog/rsyslog access to RESTRICT_SYSLOG_GROUP ** RECOMMENDED **
 RESTRICT_SYSLOG = "3"

Con lo anterior, evitarás también “molestas” alertas del tipo:

*WARNING* RESTRICT_SYSLOG is disabled. See SECURITY WARNING in /etc/csf/csf.conf.

Goodie

CSF es un estupedísimo Firewal; para el caso de este material, podría decir que no está reservado solamente para “bloquear” rangos de IP´s de países sino para implementar un cortafuego por software a tu computadora o servidor.

Por ello, si modificas, en el siguiente conjunto de líneas, puede “decidir” qué puertos deseas mantener abiertos y en qué dirección:

# Allow incoming TCP ports
TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995"

# Allow outgoing TCP ports
TCP_OUT = "20,21,22,25,53,80,110,113,443,587,993,995"

# Allow incoming UDP ports
UDP_IN = "20,21,53"

# Allow outgoing UDP ports
# To allow outgoing traceroute add 33434:33523 to this list
UDP_OUT = "20,21,53,113,123"

…e inclusive, si permitirás que hagan “ping” a tu equipo:

# Allow incoming PING
ICMP_IN = "1"

Si has despertado la curiosidad con respecto a las capacidades de CSF, te recomendamos encarecidamente dar un vistazo a todo el fichero de configuración para hacer pruebas y descubrir sus posibilidades. ¡Te encantará! Cpanel lo integra generalmente a través de WHM, lo cual nos “garantiza” en cierto sentido su mejora y mantenimiento constante.

Nota final

Si al aplicar tus reglas de Firewall con CSF te aparece el mensaje de error:

*WARNING* URLGET set to use LWP but perl module is not installed, reverting to HTTP::Tiny

Es probable que te hayas olvidado de instalar paquetes de Perl de apoyo, con lo cual, solo hace falta instalar un módulo faltante mediante lo siguiente:

sudo apt-get install libwww-perl liblwp-protocol-https-perl

¿Qué pasa en este punto? Según comentan en algunos sitios, CSF implementó el procesamiento de peticiones para HTTP y HTTPS, con lo cual, el modelo LWP::UserAgent procesa muchísimo mejor HTTPS que el modelo HTTP::Tiny.

Si quisieramos evitar usar LWP, hay que buscar la línea:

# "1" = HTTP::Tiny
# "2" = LWP::UserAgent
URLGET = "2"

Y dejarla en algo como esto:

# "1" = HTTP::Tiny
# "2" = LWP::UserAgent
URLGET = "1"
Publicado el Dejar un comentario

Análisis de logs de Apache con Scalp!

Análisis de logs de Apache con Scalp!

En temas de seguridad y protección de servidores, no existe nada mejor que proteger los mismos con aplicaciones de detección de intrusiones como Snort (https://www.snort.org/) o Suricata (http://suricata-ids.org/) u otras ofertas comerciales basadas tanto en hardware (firewalls) como Software (http://www.acunetix.com/) o servicios en la nube (https://www.cloudflare.com/) que actualizan con mayor regularidad sus bibliotecas y/o diccionarios de ataques, y están “más preparados” ante estas amenazas de la red Internet, por los que reaizar análisis de logs de Apache con Scalp! es una fantástica idea para prevenir y/o anticipar amenazas.

En esta ocasión les comparto un analizador de Logs muy sencillo, el cual propiamente, no es el más recomendado para “prevenir” ataques a un servidor Apache sino que más bien, su propósito es el de analizar potenciales huecos de seguridad o vulnerabilidades apoyándose de los registros (logs) que ha dejado atrás Apache para detectar aquellas áreas de oportunidad, mejora, e inclusive, vulnerabilidades propias de sistemas o aplicaciones desarrollados en PHP.

Scalp!, es un script analizador de logs del servidor Apache desarrollado en Phyton, que tiene como objetivo buscar problemas de seguridad. Su idea principal, es “leer” dentro de los registros de accesos al servidor para buscar patrones ataques potenciales mediante el envío de peticiones por los métodos HTTP/GET y HTTP/POST.

El sitio Web oficial de Scalp! es https://code.google.com/p/apache-scalp/.

Primeros pasos

Para los propósitos de este post, he de comentar que estoy realizando pruebas sobre Ubuntu Server 14.04. En este caso, tengo una instalación con Apache 2, PHP5 y MySQL para un servidor Web, en donde mis “logs”, se encuentran dentro del directorio /var/logs/apache2/access.log.

Con esto en consideración, lo primero que tenemos que hacer, es “descargar” el script de Scalp! en nuestro directorio favorito:

wget https://apache-scalp.googlecode.com/files/scalp-0.4.py

(Nota: te sugiero que visites regularmente la página de Scalp! para descargar la última versión actualizada).

Ahora, descargamos el archivo de expresiones regulares que utiliza PHP-IDS (otra estupenda herramienta para proteger a nuestras aplicaciones PHP) para combinarlo en su uso con Scalp! mediante el siguiente comando:

wget https://dev.itratos.de/projects/php-ids/repository/raw/trunk/lib/IDS/default_filter.xml --no-check-certificate

Ahora bien, con estos dos archivos descargados, vamos a hacer nuestro primer análisis de logs:

python scalp-0.4.py -l /var/log/apache2/access.log default_filter.xml -o scalp-output --html

En este caso, al ejecutar Scalp! por primera vez, me arrojó este mensaje de error:

The directory %s doesn't exist, scalp will try to create it
 Loading XML file 'default_filter.xml'...
 The rule '(?i:(\%SYSTEMROOT\%))' cannot be compiled properly

“Tuneando” nuestro fichero de patrones

Con respecto a la primera y segunda línea de error, no tenemos mayor problema. Más bien, el detalle que tenemos que resolver es que al parecer Phyton, no es capaz de “procesar” correctamente parte del contenido XML que descargamos de PHP-IDS. Para ello, la solución es muy sencilla, abrimos el archivo default_filter.xml con nuestro editor favorito:

nano default_filter.xml

Y alrededor de la línea 741, hay que cambiar (referencia: https://code.google.com/p/apache-scalp/issues/detail?id=8) esto:

(?i:(\%SYSTEMROOT\%))

…por esto:

(?:(\%[sS][yY][sS][tT][eE][mM][rR][oO][oO][tT]\%))

Iniciando Scalp!

Con lo anterior, guardamos los cambios, y volvemos a ejecutar el comando de Scap!

python scalp-0.4.py -l /var/log/apache2/access.log default_filter.xml -o scalp-output --html

A continuación, les aparecerá un mensaje como este, ante el cual, solo tenemos que esperar un poco (en función del tamaño de archivo de tu log o de las reglas que hayas pedido ejecutar):

Loading XML file 'default_filter.xml'...
 Processing the file '/var/log/access.log'...
 Scalp results:
 Processed 491229 lines over 491413
 Found 3175 attack patterns in 177.725208 s
 Generating output in scalp-output/access.log_scalp_*

Ahora, solo tienes que ir al directorio scalp-output y “visualizar” en tu navegador en archivo generado para visualizar el reporte completo de patrones de ataque observados.

¡Esta herramienta es genial!

Goodie

Tecleando el comando:

python scalp-0.4.py --help

…podrás obtener la ayuda relacionada con otros patrones de uso de Scalp!.

Scalp the apache log! by Romain Gaucher - http://rgaucher.info
 usage: ./scalp.py [--log|-l log_file] [--filters|-f filter_file] [--period time-frame] [OPTIONS] [--attack a1,a2,..,an]
 [--sample|-s 4.2]
 --log |-l: the apache log file './access_log' by default
 --filters |-f: the filter file './default_filter.xml' by default
 --exhaustive|-e: will report all type of attacks detected and not stop
 at the first found
 --tough |-u: try to decode the potential attack vectors (may increase
 the examination time)
 --period |-p: the period must be specified in the same format as in
 the Apache logs using * as wild-card
 ex: 04/Apr/2008:15:45;*/Mai/2008
 if not specified at the end, the max or min are taken
 --html |-h: generate an HTML output
 --xml |-x: generate an XML output
 --text |-t: generate a simple text output (default)
 --except |-c: generate a file that contains the non examined logs due to the
 main regular expression; ill-formed Apache log etc.
 --attack |-a: specify the list of attacks to look for
 list: xss, sqli, csrf, dos, dt, spam, id, ref, lfi
 the list of attacks should not contains spaces and comma separated
 ex: xss,sqli,lfi,ref
 --output |-o: specifying the output directory; by default, scalp will try to write
 in the same directory as the log file
 --sample |-s: use a random sample of the lines, the number (float in [0,100]) is
 the percentage, ex: --sample 0.1 for 1/1000

Si te interesa el tema, aquí puedes encontrar un estupendo artículo (en inglés) sobre una comparativa entre Snort y Suricata, los IDS (intrusion detection system) Open Source más populares. La liga es: http://wiki.aanval.com/wiki/Snort_vs_Suricata