Archive for the ‘Hosting’ Category

ProxyBL.org

De la mano de SunBelt me entero de este interesante proyecto. Se trata de una RBL como las que muchos de nosotros usamos en los servidores de correo como filtros basados en IP (véase spamcannibal, por ejemplo) pero ésta filtra proxies anónimos y/o abiertos al público.

No he tenido la oportunidad de probarla, pero en cuanto disponga de más tiempo actualizaré esta entrada. Si alguno de vosotros ya la conocía o quiere dejar su opinión aquí, bienvenido sea.

Visitar ProxyBL.org

[ad]

Seguridad: phpMyAdmin 4.0 Corporate

Existe una vulnerabilidad XSS en pmd_pdf.php que permite a atacantes remotos inyectar código (script o HTML) usando el parámetro de script db cuando register_global está activo.

La vulnerabilidad encontrada en tbl_structure.php permite a un atacante remoto inyectar código y ejecutar código arbritrario usando el parámetro de tabla del script.

Otra vulnerabilidad permite al atacante inyectar código usando los vectores relacionados con el script del parámetro de la tabla.

Como siempre, lo mejor es actualizar usando urpmi o MandrivaUpdate. Tenéis más información acerca de estos fallos de seguridad en los siguientes enlaces:

Primero, segundo y tercero.

Fallo de seguridad en Samba (3.2.0 – 3.2.6)

Es posible acceder al directorio raíz del recurso compartido conectando a “” (ua cadena vacía de caracteres) usando smbclient, por ejemplo con:

smbclient //server/ -U user%pass

El acceso al sistema se produce con los permisos del usuario autenticado. Este problema únicamente ocurre con la variable registry_shares = yes la cual también implica tener include = registry y config backend = registry pero no es la configuración por defecto. Un parche está disponible en la página web de Samba. Lo recomendable sería actualizar, aplicar este parche o bien deshabilitar la variable en cuestión (registry shares = no).

Podéis encontrar más información al respecto aquí.

Cómo asegurar un servidor cPanel.

Como creo que mucha gente usa este tipo de páneles de control, intentaré traducir un documento acerca de la seguridad de este panel de control sobre Cent OS, realizado por Krun!x y que me encontré aquí.

Bueno, comenzamos.

1. Actualizar Apache/PHP, MySQL, OpenSSH, OpenSSL, CP/WHM, etc.

2. Configuración cP/WHM.

3. Acceso SSH.

4. Mod_Security.

5. Firewall.

6. Proteción contra DDoS.

7. RootKits.

8. Configuración PHP.

9. Otros.

10. Fin.

Hola a todos, en primer lugar os pido perdón por mi inglés, ya que no es mi lengua nativa. He escrito un tutorial sobre la seguridad en los servidores, cómo securizar servidores web. Uso Cent OS, Apache y cP/WHM. Explicaré cómo asegurarlos.

Empecemos :)

  • 1. Actualizar Apache/PHP, MySQL, OpenSSH, OpenSSL, CP/WHM, etc.

Actualiza tu Apache/PHP, MySQL, OpenSSH, OpenSSL, cP/WHM y asegúrate de que tengas la última versión segura y estable.

  • 2. Configuración cP/WHM.

WHM – Configuración de servidor – Parámetros de seguridad:

- Activar: php_openbase_dir, mod_userdir, proteción contra shell bombs y/o memory bombs.

- Desactivar: Compilador, excepto para el usuario root.

WHM – Ajustes en las cuentas.

- Desactivar: Modo demostración del panel de control, acceso (a través del shell) de todas las cuentas menos al usuario root.

WHM – Configuración de servicios – Configuración de FTP.

- Desactivar: Acceso al FTP como usuario anónimo.

WHM – MySQL.

- Escoge una password para tu servidor MySQL (no pongas la misma que usas para el usuario root). Si no eliges una contraseña para MySQL y alguien sube una shell como c99 al servidor podrá hacer login al servidor de bases de datos como root sin contraseña y podrá eliminar, borrar o bajar cualquier base de datos del servidor.

WHM – Configuración del servidor.

- Activa suEXEC y PHPsuEXEC.

Cuando PHP se ejecuta como módulo en Apache, éste se ejecuta normalmente como usuario “apache” o “nobody”.

PHPsuEXEC cambia esto y ejecuta los scripts como CGI’s. Esto significa que los scripts son ejecutados con los permisos del usuario que creó el script. Los permisos del script no podrán ser 777 (ejecución, lectura y escritura para todos).

  • 3. Acceso SSH.

Cambia el puerto de acceso para SSH (pon algo como 1334). Pudes cambiarlo en /etc/ssh/sshd_conf. Hay un montón de Script Kiddiez con programas brute force e intentan crackear nuestra password porque ellos saben que el nombre de usuario es root y el puerto es el 22. Pero como somos más inteligentes, vamos a cambiar este puerto. Este proceso de brute force puede consumir ancho de banda, por lo que hará más lento el tiempo de respuesta del servidor.

El mensaje legal de SSH. Edita /etc/motd y escribe algo como esto:

“¡Alerta! Esto es un área restringida y el administrador ha sido notificado.”

Cuando alguien intente entrar al servidor a través de SSH, le aparecerá el mismo mensaje que acabas de editar. Finalmente, deberás reiniciar SSH con la orden: service sshd restart

  • 4. Mod Security.

ModSecurity es una aplicación que funciona como un cortafuegos para tu web y que puede asegurarla contra: RFI, LFI, XSS, SQL Injection, etc. Si usas cP/WHM puedes habilitarlo fácilmente: Plugins, activar ModSecurity y salva los cambios.

Ahora explicaré cómo instalar ModSecurity desde el código. No podrás instalar ModSecurity si no tienes los siguientes paquetes ya instalados: libxml2 y la librería http-devel. También tendrás que activar mod_unique_id en los módulos de Apache, pero no te preocupes, te explicaré cómo hacerlo :) .

Accede a través de SSH y escribe:

yum install limxml2 libxml2-devel http-devel

Esto instalará estos paquetes.

Ahora necesitas editar el archivo de configuración de Apache que lo puedes encontrar en: /etc/httpd/conf/httpd.conf

Necesitas añadir lo siguiente:

LoadModule unique_id_module modules/mod_unique_id.so

Ahora descarga la última versión de ModSecurity para Apache v2 desde http://modsecurity.org:

cd /root/downloads/

wget http://modsecurity.org/download/modsecurity-apache_2.5.6.tar.gz

tar xzf modsecurity-apache_2.5.6.tar.gz

cd modsecurity-apache_2.5.6.tar.gz

cd apache2

./configure
make
make install

De nuevo edita httpd.conf y añade:

LoadFile /usr/lib/libxml2.so

LoadModule security2_module modules/mod_security2.so

Include /etc/httpd/conf/modsecurity.conf

El contenido del modsecurity.conf lo tenéis en la fuente original, a partir de la línea en donde pone: content of /etc/httpd/conf/modsecurity.conf. Analizarlo detenidamente antes de incluirlo para saber bien cómo funciona y si os puede ocasionar algún problema cualquier de las reglas que contiene.

Ahora, reinicia Apache:

service httpd restart

  • 5. Firewall

Instalaremos APF (Advanced Policy Firewall). APF es un cortafuegos basado en IP Tables diseñado para ser fácil de usar y configurar.

Entra en el servidor y escribe:

cd /root/downloads/

wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz

tar -xfvz apf-current.tar.gz

cd apf-0.9.5-1 // O cualquiera que sea la versión.

./install.sh

Os aparecerá un mensaje de que ha sido instalado con éxito, y algunas rutas acerca de las configuraciones. Ahora pasemos a configurar nuestro nuevo cortafuegos. Necesitamos editar apf.conf, que está en /etc/apf/conf.apf

Si usas cP/WHM, como yo, necesitas configurar APF de la siguiente manera (para que podamos acceder a cP/WHM, ya que por defecto APF bloquea el acceso a estos puertos).

La configuración también la tenéis en la fuente original. Empieza en donde aparece: “common ingress (inbound ports)” y termina hasta donde está marcado con una línea de guiones bajos. Revisadla bien por si acaso y sobre todo si tenéis los puertos diferentes a éstos.

Luego en el fichero: apf.conf deberéis cambiar la variable DEVM de 0 a 1. Ahora nos toca arrancar APF:

apf -s

Otros parámetros:

-r reinicia APF.

-f Vacía el firewall (limpia las reglas).

-st Muestra un status del firewall.

-d IP Banea dirección IP.

-u IP Elimina el baneo de una dirección IP.

  • 6. Protección DDoS.

Instalaremos el módulo para Apache mod_evasive, que sirve para prevenir este tipo de ataques al servidor. Para instalarlo entra por SSH a tu servidor y escribe:

cd /root/downloads

wget http://www.zdziarski.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz

tar xfvz mod_evasive_1.10.1.tar.gz

cd mod_evasive

/usr/sbin/apxs -cia mod_evasive20.c

Cuando mod_evasive esté instalado, pon las siguientes líneas en tu httpd.conf

--------------------------------
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
</IfModule>
--------------------------------

Ahora vamos a proceder a instalar DoS Deflate. Para hacerlo, haz lo siguiente:

wget http://www.inetbase.com/scripts/ddos/install.sh
chmod 0700 install.sh
./install.sh

Y para desinstalarlo haremos esto otro:

wget http://www.inetbase.com/scripts/ddos/uninstall.ddos
chmod 0700 uninstall.ddos
./uninstall.ddos
  • 7. Rootkits.

Bien, vamos a instalar rootkithunter. RootkitHunter es una herramienta que te asegura al 99% de que estás limpio de programas peligrosos. Busca rootkits, backdoors y exploits locales haciendo pruebas como comparar MD5, ficheros ocultos, etc.

  • 8. Configuración PHP.

Necesitamos modificar php.ini, el cual puedes encontrar en /usr/local/lib/php.ini:

safe_mode = On
expose_php = Off
magic_quotes = On
register_globals = off
display errors = off
disable_functions = show_source, system, proc_terminate,
shell_exec, exec, passthru, proc_open, phpinfo, popen

Si estás usando cP/WHM puedes configurarlo desde el mismo en configuración de servicio y posteriormente en editor de configuración para PHP.

  • 9. Otros.

Si estás usando NAMED (BIND), tienes que editar /etc/named.conf y añadir:

recursion no;

bajo la opción Options {

Ahora reinicia BIND con: service named restart. Ésto bloqueará las peticiones desde dnstools.com y similares que causan lentitud en el servidor.

Ahora lo que haremos será prevenir el IP Spoofing editando el fichero /etc/host.conf y añadiendo:

order bind,hosts

nospoof on

También ocultaremos la versión de Apache con la siguiente opción en httpd.conf:

ServerSignature Off

Deshabilitaremos telnet editando /etc/xinetd.d/telnet:

disable = yes

  • 10. Fin.

Este es el final del artículo acerca de cómo asegurar un servidor y espero que te haya ayudado a hacer más seguro tu servidor.

Autor original: Krun!x

Fuente original en inglés: http://packetstormsecurity.nl/papers/general/server_security.txt

Hosting para góticos.

Navegando como suelo hacer por la mañana mientras tomo café, me encontré con esta empresa la cual me deja boquiabierto y no es por sus precios, sino por el nombre de la misma y el diseño de su página web. Se trata de Dracula Hosting y la página web la podéis ver haciendo click aquí. No tiene desperdicio.

Serversniff: la navaja suiza.

Se que muchos de vosotros pensaréis que ya tenéis esto en vuestra distribución de GNU/Linux o *BSD, etc etc pero tambiéne staréis de acuerdo conmigo en que mucha gente verá esta página web de gran utilidad, sobre los que trabajan en el gremio del hosting (soporte, etc) y necesitan que el usuario compruebe por sí mismo (entre otras muchas cosas) conectividad, pruebas de conexión desde otra línea que no sea la suya, etc etc.

Pues, la web que me acabo de encontrar es ServerSniff, y tenéis todo lo que necesitáis: pruebas de DNS, de SSL, whois, robots.txt…

El 90% de las páginas web de internet pueden ser comprometidas.

De nuevo, os traigo una traducción de un curioso artículo que me encontré:

Después de los esfuerzos reiterados de investigadores sobre la seguridad informática, buscadores, empresas de hosting para ayudar a los webmasters a comprender el grado de importancia de los ataques que existen en internet – y en particular el alcance de los métodos usados para explotar páginas webs – los resultados de WhiteHat Security nos dicen que la cosa va a peor.

En un nuevo reporte, WhiteHat – la organización de seguridad sobre aplicaciones web fundada por Jeremiah Grossman – concluye que al menos un 90% de los sitios que ha escaneado en el último año permanecen vulnerables a cualquier tipo de ataque o infección.

El principal problema es es la seguridad de los sitios contra los ataques XSS, según el reporte.

Information leakage – o la habilidad para entrar en áreas en donde se guarda la información sensible – es otro problema serio, según dice la compañía, que reportó una lista de problemas de todos las vulnerabilidades encontradas entre los sitios web que probaron – incluyendo los ataques XSS.

WhiteHat también subrayó el crecimiento de otro tipo de ataques incluyendo SQL Injection y HTTP Response Splitting. Lo peligroso de esos ataques pueden estar directamente relacionado con el uso en alza de la identificación de tecnologías, en lo que a firmas se refiere.

Esta compañía comenta que este tipo de ataques son los menos contemplados e incomprendidos, y que evaden la mayor parte de herramientas de escaneo. Como resultado, los ataques “son muy peligrosos y con consecuencias fatales“, dijo. En un post reciente en su blog, Grossman describió los ataques HTTP Response Splitting como lo siguiente:

la mejor forma de ver el Response Splitting es que funciona parecido al XSS (Cross Site Scripting), pero es más poderoso.Míralo como si fuera una carta escrita dentro de un sobre. XSS ataca al mensaje de adentro, sin embargo HTTP Response Splitting ataca no sólo al contenido del sobre, sino al sobre en sí“.

Existen muchas tipos y variaciones de este ataque, lo que hace su identificación todo un desafío , así como encontrar la vulnerabilidad“.

WhiteHat también empezó a advertir a la gente acerca del aumento de la falsificación XSS.

Como parte del reporte anual de WhiteHat la compañía empezó a observar la forma en que las vulnerabilidades parecen ser más populares en las empresas.

Por ejemplo, la compañía encontró que mientras la seguridad web fue débil en general, el sector de venta al público securizó sus URLs mejor que otros mercados. Como en el resto de internet, las vulnerabilidades XSS son seguidas de cerca por la “fuga de información”.

Estas estadísticas revelan que las vulnerabilidades siguen afectando a los sitios de empresas”, dijo Grossman que lleva el título de CTO en WhiteHat. “Debido al incremento de almacenamiento de información online, WhiteHat permanece alerta advirtiendo a compañías de ataques comunes y enfatizando en la importancia de la seguridad en las páginas web como parte de su postura de seguridad total“.

Posteado por Matt Hines on October 15, 2007 01:23 PM y traducido por Jacob F.P.

10 secretos sucios del web hosting gratis. Lo que no quieren que sepas.

Navegando por Go Articles me encuentro con este que traduzco más abajo, bastante interesante:

1.- No proporcionan servicio de soporte las 24 horas los 7 días de la semana. El soporte al cliente parece no ser importante ahora, pero el primer problema que tengas, hubieras deseado escoger una empresa con mejor servicio de cara al cliente. Hay más cosas de las que preocuparse en la vida que el servicio técnico de tu página web, escoge una empresa que te de bien servicio.

2.- No te ofrecen información estadística de tu web. Con un servicio de web gratis, pierdes un montón de información que con un servicio de pago tendrías. Por ejemplo, ¿sabes cuántas visitas has tenido este mes? Si no tienes estadísticas, no sabrás si tu negocio va bien.

3.- Te obligan a tener banners en tu página. Éstos hacen verse a tu página poco profesional. Normalmente, estos banners de publicidad no tienen nada que ver con el contenido de tu página web. Supone una distracción para tus clientes. A unas malas, pueden ver algo que les interese y abandonan tu página para irse a la que la publicidad les mostró.

4.- No tienes acceso FTP. Pregúntale a cualquier programador si el acceso FTP es esencial para una página web a medida. Sin él, no podrás subir la información de tu web al completo. Pero además, tendrás que subir los archivos uno por uno. Esto puede hacerte perder el tiempo, sobre todo para páginas webs grandes.

5.- No te garantizan la disponibilidad de la página. La mayoría de las buenas compañías garantizan una disponibilidad del 99%, sin embargo las compañías de hosting gratis no pueden sostener este uptime, no garantizándolo. Cada minuto que pasa y tu página web está caída, pierdes dinero. Piensa que el coste de un buen hosting es lo que vas a perder si esto ocurre.

6.- No te permiten usar tu propio nombre de dominio. Normalmente debe ser un subdominio de su dominio principal. Esto hará que la longitud de tu página sea mayor y sea más difícil de aprender para los clientes y por consiguiente más difícil de encontrar.

7.- No les gusta que metas software com Joomla o Wordpress. Esto hace que el mantenimiento de la página sea mucho mucho más fácil de llevar. Muchas empresas de hosting de pago, no sólo te dejan tener este tipo de software en tu alojamiento, sino que además lo proveen de forma gratis.

8.- No te dan suficiente espacio en disco o transferencia al mes. Éste varía dependiendo de para qué vayas a usar el hospedaje pero generalmente no te ofrecen suficiente.

9.- No te dan cuentas de correo con el servicio. Aunque seas una pequeña empresa, necesitas al menos de 5 direcciones de correo para que los clientes contacten contigo. Se ve muy poco profesional si tienes un correo para tu empresa del tipo pepe@hotmail.com o cualquier de los demás servicios de correo gratis que existen.

10.- Sólo tienen un servidor. Mientras que un servidor es suficiente para la mayoría de las ocasiones, qué ocurre siel servidor necesita mantenimiento o peor aún, que se estropea en el momento menos oportuno. No tendrás página web porque los servicios de web hosting gratis no tienen servidor backup.

Acerca del autor:

Este artículo ha sido escrito por Joe Arieno CEO de WebHost-Associate.com. Si te gustó este artículo y te gustaría saber qué cuesta poner tu empresa en internet visita WebHost-Associate.com y cuando estés listo te enseñaremos de montar una página web que satisfaga TODAS LAS NECESIDADES DE TU NEGOCIO!!

Traducido por Jacob F.P.

¿Tu página web es segura? Pruébalo.

en el blog de ModSecurity me encuentro con el siguiente post. No tiene desperdicio y la verdad es que es 100% verídico. No hay que dejarse guiar por las apariencias y extremar precauciones en lo que a seguridad informática se refiere. Traduzco:

Así que, ¿tu página web es segura? Pruébalo.

1. Sí, lo es.

Entonces, se oyen grillos (silencio para los colegas poco imaginativos). Esto es completamente inaceptable. El fallo está en proporcionar seguridad con palabras. Queremos seguridad, pero con hechos. Piénsalo de esta forma: ¿un auditor se conformaría con esa respuesta? ¿Podrías pasar una auditoría PCI con responder sí?. No verdad, entonces necesitas demostrarlo con hechos.

2. Sí lo es. Tenemos el producto X, Y, Z, etc.

Esto es mejor, pero es otra de las expresiones que se basan en las palabras y no en los hechos. El único hecho es que la tecnología puede ser manipulada, invertida y comprometida. Puede ser efectiva contra un modelo de ataque y complétamente débil contra otro.

Esto me recuerda a una respuesta que suelen dar mucho: “Sí, porque usamos un certificado SSL“. Ugh… déjame contarte algo sobre los certificados SSL que pude sufrir con una de estas webs. Hace tiempo decidí hacer una compra online de unas hierbas que pueden calentarse en el microondas, para los músculos. Cuando visité la página web del fabricante fuí sorprendido con un mensaje que decía: ¡Somos un sitio web seguro! Usamos un SSL de 128 bits. Esto demostraba que mi número de tarjeta de crédito no se enviaría en texto plano. Durante el proceso de compra, decidí verificad la información del certificado SSL. Hice doble click sobre el candado que aparece en la parte inferior derecha y verifiqué si el dominio al que pertenecía el certificado SSL era el correcto y coincidía con la dirección que estaba visitando el cual estaba firmado por una empresa de renombre como Verisign y que, finalmente, el certificado era válido. Todo parecía estar en orden así que procedí con la compra e introducí los datos de mi tarjeta de crédito. Pulsé el botón de comprar y me mostró un mensaje que hizo que mi estómago diera un vuelco. El mensaje viene a continuación, de cualquier forma, he modificado la información para protegerme a mí y a mi banco:

To:companyname@aol.com
From: RCBarnett@email.com
Subject:ONLINE HERBPACK!!!
name: Ryan Barnett
address: 1234 Someplace Ct.
city: Someplace
state: State
zip: 12345
phone#:
Type of card: American Express
name on card: Ryan Barnett
card number: 123456789012345
expiration date: 11/05
number of basics:
Number of eyepillows:
Number of neckrings: 1
number of belted: 1
number of jumbo packs:
number of foot warmers: 1
number of knee wraps:
number of wrist wraps:
number of keyboard packs:
number of shoulder wrap-s:
number of cool downz:
number of hats-black:         number of hats-gray:
number of hats-navy:         number of hats-red:
number of hats-rtcamo:         number of hats-orange:
do you want it shipped to a friend:
name:
their address:
their city:
their state:
their zip:
cgiemail 1.6

No podía creerlo. Tal y como pensaba han enviado mis datos bancarios en texto plano a una cuenta de correo de AOL. ¿Cómo es posible? Fueron lo intelitgentes como para que la información del usuario fuera enviada con SSL de 128 bits a la página web, ¿por qué no hicieron lo mismo con el proceso de envío de la información? Debe haber un error. En el correo se podía ver un mensaje que indicaba que la aplicación usada para el pedido era CGIMAIL 1.6. Al instante me puse a buscar información en Google. Encontré un enlace para webmasters acerca de CGIMAIL. Rápidamente revisé el contenido y encontré lo que estaba buscando: ¿qué consejos acerca de la seguridad de CGIMAIL existen?:

Intercepción de los datos enviados por un navegador al servidor y viceversa.

Riesgo: con CGIMAIL al igual que en muchos programas de envío de correos a través de formulario se puede esnifar en cualquier punto entre el servidor web y el usuario. Como no hay encriptación, no es recomendable usarlo para información confidencial o números de tarjetas de crédito.

Bingo, tal y como sospechaba. Gasté el resto del día intentando contactar con mi banco acerca de la posibilidad de que hubieran comprometido la información de mi tarjeta de crédito y para echarle un ojo a mi cuenta. También contacté con la compañía enviando un correo electrónico a la misma dirección de AOL haciendo incapié en la falta de seguridad que tenían en su proceso de compra. Resumiendo: usar SSL no es sinónimo de seguridad.

3. Sí, tenemos certificación PCI.

Generalmente hablando, son como requerimentos que se prueban con una lista de pruebas escritas en papel los cuales controlan ataques. PCI es la excepción e intenta ser más relevante en lo que a problemas de seguridad en una web se refiere. Aunque hay ciertos aspectos buenos de PCI, por favor ten esto presente siempre:

Es mucho más fácil aprobar una auditoría PCI si eres seguro que ser seguro porque tienes que pasar una auditoría PCI.

PCI, como otras muchas, es un estándar mínimo de cuidado y pasar el test hace tu sitio “unhackeable”. Para una empresa sería como meterse en en océano con unos chalecos y botes salvavidas, saliendo seco previamente del puerto. Si el cumplimiento de estas reglas y premisas va más allá de un papel escrito, nos vamos acercando a la verdadera evidencia. De todas formas, no he visto ninguno de estos con evidencia real. Revisa el post de Richard en su blog en cumplimiento de controles de seguridad para más detalle acerca de esto y qué está mal. Lo que realmente necesitamos es más “evaluacion de campo”. Hablaré acerca de esto en posts posteriores en mi blog.

4. Sí, tenemos logs indicando que hemos evitado ataques web X, Y y Z (SQL Injection, XSS, etc).

Esto se va acercando a la respuesta correcta, pero aún no es la respuesta adecuada. Por primera vez tenemos evidencia (logs) pero éstos probablemente no tienen el “retrato” correcto. Creo que la forma en que la gente monta y usa un WAF es incorrecta. La mayoría de la gente monta un WAF centrándose en dar alertas que sólamente proporciona logs cuando coincide una de nuestras reglas. Claro, esos WAF detectan y paran un ataque potencialmente peligroso pero, ¿qué hay de lo que hizo en todo el proceso? ¿Fueron ataques normales o hubo algún que otro potencialmente perligroso y no reconocido por el mecanismo de prevención? Montar un WAF a nivel HTTP es una opción muy buena raramente usada. Existe una antigua cita que recoge este concepto:

“En un incidente, si no tienes buenos logs (p.e auditar) deberás tener buena suerte.”

5. Sí, no tenemos ninguna indicación de que nuestras aplicaciones web estén respondiendo a los patrones de los ataques.

Alguien podría llamar a esto racionalmente el concepto de seguridad. El que esta pregunta sea aceptable o no depende de la naturaleza de las indicaciones. Si no tienes ningún indicio porque no estás monitoreando nada, entonces la escusa es absurda. Si no tienes ningún indicio y auditas el estado de una aplicación web, entonces estamos avanzando. Esto lidera parte de la respuesta siguiente, que se acerca mucho a la pregunta ideal.

6. Sí, no tenemos ningún indicio de que nuestra aplicación esté interactuando con el exterior respondiendo a patrones y estamos tomando, analizando y escalando redes, hosts y ataques a aplicaciones web y violaciones de éstas.

Estamos muy muy cerca de la respuesta correcta. La ausencia de evidencia de intrusión es significativa si estás seguro de que estás correctamente instrumentado y conoces a fondo la aplicación web. Debes monitorear concienzudamente el servidor para que la aplicación web sea “segura”. La falta de una fuerte auditoría de los logs es la razón más común por la que las empresas no pueden contestar de esta forma. Velo de la siguiente forma: Common Log Format (CLF) no so adecuados para una respuesta rápida y adecuada ante un incidente. Falta mucha información. Si esta respuesta está muy cerca de la correcta, ¿por qué no lo es?

7. Sí, no tenemos ningún indicio de que nuestra aplicación esté interactuando con el exterior respondiendo a patrones y guardamos, analizamos y escalamos una variedad de host, redes y evidencia basada en aplicaciones web de intrusiones. Habitualmente testeamos nuestra detección y equipo de repuesta, procesos y utilidades haciendo simulacros que coinciden o exceden las capacidades e intenciones de las amenazas que tenga nuestra empresa.

Aquí puedes ver por qué la respuesta seis era insuficiente. Si crees que la respuesta 6 es suficiente, olvidaste que tus van más allá que detectar y reportar las intrusiones. Periódicamente debes probar la efectividad de tu defensa con ejercicios neutrales. La respuesta final es una suma de las demás y de que conoces la aplicación que estás intentando asegurar. Piensa sobre este ejercicio, si realizas un ataque sin que los del equipo de respuesta lo sepa, ¿cómo responde tu empresa? ¿Se han dado cuenta de la prueba que hiciste ellos solos? ¿Escalaron el problema de forma correcta? ¿Cuánto tardaron después de adoptar las medidas oportunas? Si no tienes respuestas para este tipo de ataques en directo, seguramente no sabrás cuán efectiva es tu defensa.

Conclusión.

Indirectamente, este post tambin explica por qué sólo: escaneo de vulnerabilidades web, pruebas de penetración, montaje de un firewall para la aplicación web y análisis de logs no es suficiente para una buena “seguridad”. Mientras cada uno de estos puntos ayuda a la seguridad de un sitio web, son inefectivas en otras. Es el conjunto de todos esos esfuerzos lo que hace que algunas organizaciones tengan un sitio web “que se defiende”, como Richard dice.

Posteado por rcbarnett at January 30, 2008 12:45 PM y traducido por Jacob F.P

Fuente: ModSecurity Blog.

Nuevo motor de búsqueda para exploits.

Vía Security Focus me llega vía e-mail un nuevo motor de búsqueda para vulnerabilidades y exploits que puede ser de gran ayuda a la hora de buscar fallos, y auditar nuestros servidores:

El motor de búsqueda se llama Exploit Search, y podéis probarlo haciendo click aquí.

Return top