Mostrando las entradas con la etiqueta Servidores. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Servidores. Mostrar todas las entradas

4 de julio de 2016

Hardening de sistemas GNU/Linux por @lawwait

Hoy les quiero compartir una excelente conferencia de Lorenzo Martinez @lawwait uno de los escritos del blog Security By Default y creador de Securizame para la Campus Party México 2016 • #FeelTheFuture.

f
Figura 1: Lorenzo Martinez en su presentación.
Para esta conferencia les recomiendo tener a mano papel y lápiz para realizar las anotaciones en cada uno de los tips que Lorenzo nos va enseñando. Muy buen punto de vista para la implementación de DMZ, hardening de Kernel y recomendaciones generales.

Que disfruten de la conferencia.


Saludos!

12 de julio de 2015

Instalar y configurar un servidor Bind9

Muy buen tutorial que me gustaría compartir con ustedes, donde Roberto Rodriguez Luna explica de forma detallada la forma de instalar y configurar un servidor DNS con Bind9.

Con esto, todos podemos implementar rápidamente nuestro propio servidor y hacer uso de todas las prestaciones de Bind9


Saludos!

16 de junio de 2015

Activar mod_evasive en Apache2

mod_evasive es un módulo que podemos activar en el servidor HTTP Apache y que nos permite proteger nuestro servicio por ataques de fuerza bruta al puerto 80 o las Denegaciones de Servicios, que en estos últimos años se volvieron tan populares.


Es de uso indispensable, ya que lograr configurarlo es sumamente simple y nos puede ayudar mucho en la tarea de prevención de los vectores de ataques mencionados anteriormente.

Para lograr activarlo correctamente en Apache2 utilizando como base un sistema Debian podemos hacer los siguientes pasos:

$ apt-get install libapache2-mod-evasive

Luego, ingresamos al directorio donde se encuentran los módulos disponibles de Apache2

$ cd /etc/apache2/mods-available
$ ls -l

y vamos a ver que se encuentra los archivos evasive.conf y evasive.load

Por otro lado creamos un directorio donde se van a encontrar los log de este módulo

$ mkdir /var/log/mod_evasive

y editamos el archivo evasive.conf quitanto todos los "#" de comentarios. En otro post voy a explicar de forma detallada cada uno de los parámetros que podemos configurar

Finalmente nos queda activar el módulo en apache2 de la siguiente manera:

$ a2enmod evasive
$ /etc/init.d/apache2 restart

Es posible verificar que el módulo se encuentra activo y funcionando de la siguiente manera:

$ apache2ctl -M | grep evasive

Realmente es muy simple, rápido y muy efectivo y a partir del día 0 de la implementación de Apache2 podemos tener el control de este tipo de ataques.

Saludos!

26 de mayo de 2015

Infraestructura como Servicio

Infraestructura como servicio, es una de las formas de sacar partido sobre el concepto de la Nube, por otro lado, proporciones prácticamente ilimitadas a las empresas que necesitan adaptar sus recursos de servidores y almacenamiento rápidamente y por sobre todas las cosas, a demanda.




La infraestructura como servicio (infrastructure as a service, IaaS) -también llamado en algunos casos hardware as a service, HaaS) se encuentra en la capa inferior y es un medio de entregar almacenamiento básico y capacidades de cómputo como servicios estandarizados en la red. Servidores, sistemas de almacenamiento, conexiones, enrutadores, y otros sistemas se concentran (por ejemplo a través de la tecnología de virtualización) para manejar tipos específicos de cargas de trabajo —desde procesamiento en lotes (“batch”) hasta aumento de servidor/almacenamiento durante las cargas pico. 

Conociendo este concepto, me gustaría invitarlos desde el blog a ver y analizar las alternativas que encontramos en el mercado como System Canter, OpenStack, OpenNebula, CloudStack, entre los más populares, para poder implementar IaaS en nuestras organizaciones y lograr consolidar nuestra infraestructura, generando confianza en la robustez, escalabilidad y seguridad.

Saludos!

11 de mayo de 2015

Plataforma de Logueo y Monitoreo dinámico

Los sistemas de monitoreo son indispensables en toda infraestructura de servidores, como saber qué componente funciona bien o mal, cuándo es que ocurren los problemas y conocer las estadísticas del funcionamiento es algo que no debemos dejar pasar por alto.

Los chicos de nerdear.la en un tweet me pasaron el enlace de su canal de YouTube para disfrutar algunas de las charlas del 2014 y la verdad que me gustó mucho la charla llamada "Plataforma de Logueo y Monitoreo dinámico" y es por ello que les recomiendo que a medida que vean la conferencia, papel y lápiz en mano por que hay muchas herramientas y mucha data para investigar.


Fantástico verdad?

Saludos!

10 de febrero de 2015

Google Hacking: Servidores Apache2 en Ubuntu Server

Regresando a las búsquedas de algunos Dorks dentro de Google, me topé con una configuración por defecto dentro de la distribución Ubuntu Server en referencia al servidor web Apache2.

Esto lo descubrí, cuando estaba instalando dentro de Ubuntu Server, todo el entorno y ecosistema de OpenStack y sus componentes, donde en algún momento, dentro del blog vamos a estar hablando.

Uno de sus componentes se llama Horizon y se trata de un Dashboard web donde nos permite interactuar directamente con todos los componentes de OpenStack y desplegar los servidores, y obviamente este dashboard necesitaba de un servidor web como Apache2

El tema es que mientra instalaba, note que sobre esa IP aparecía una página customizada por Ubuntu Server con la frase que todo SysAdmin busca “It works” pero algo diferentes.


Para sacarnos la duda, vamos directamente a realizar una búsqueda masiva para ver cuanto indexó los motores de Google.

intitle:"Apache2 Ubuntu Default Page: It works"


Casi 3.000 servidores corriendo Ubuntu Server y atendiendo un servicio Apache2, donde además, dejaron la configuración por defecto.

Lo ideal sería cambiar o eliminar el VirtualHost que apache trae por defecto al momento de su instalación y evitar que una vez más Google meta las narices y continúe indexando más y más cosas.

Saludos!

12 de enero de 2015

Como buscar posible #malware en tus servidores web

Este es un método que utilizo para monitorear constantemente alguno de los servidores webs que administro, todos basados en tecnología LAMP.


Ustedes saben que un posible atacante que compromete una web generalmente intenta ocultar la información haciendo uso de la función para PHP llamada base64_encode y base64_decode. Esto lo hacen por una simple razón lógica, la idea es ocultar cosas tan obvias que hasta un programador Jr lo podría descubrir y para ellos hacen uso de esas funciones.

base64_encode — Codifica datos con MIME base64, este tipo de codificación está diseñado para que datos binarios sobrepasen capas de transporte que no son de 8-bits 100%, como por ejemplo el cuerpo de un E-Mail.

base64_decode — Decodifica datos codificados con MIME base64.

La codificación en Base64 hace que los datos sean un 33% más largos que los datos el originales.

Entonces para no estar buscando por todos lados y perder el orden de las cosas voy a hacer uso de la consola y un pequeño pero poderoso comando llamado grep

Suponiendo que el virtual host de un usuario sea /home/usuario/public_html/ o bien sea el clásico /var/www/ ingresamos a dicho directorio que queremos realizar busquedas y ejecutamos:

$ grep -ail -e "base64_encode(" -e "base64_decode(" . -R

A partir de aquí podemos encontrar cosas tan bonitas como estas.


Bien escondido el base64_decode() pero evidentemente no para grep.

Con esto no significa que no encontremos falsos positivos, yo lo utilizaría más para realizar una búsqueda rápida y dirigida hacia determinados archivos y directorios.

A hora queda poner en práctica lo aprendido y dejarme sus comentarios.

Saludos!

2 de julio de 2014

Ambientes de pruebas y producción

Cuando nos encontramos en una situación en la que por algún motivo nuestro ambiente actual de producción debe ser modificado, actualizado o cambiar de un estado a otro, es necesario, para evitar  los riesgos de una posible caída del sistema o degradación del mismo, imitar varios escenarios similares y lograr ensayar esos cambios allí.


Un ambiente de producción, es un ambiente sumamente controlado, tanto por los recursos que están involucrados como en las configuraciones de cada sistema o servicio, en tanto que un ambiente de pruebas lo podemos considerar como un escenario con poco control, en donde generalmente podemos modificar todos sus componentes sin miedo o temor a “romper” algo.

Hoy en día, gracias a las tecnologías de virtualización, es muy simple crear entornos de prueba basados en un entorno de producción, para que el escenario sea lo más parecido al que luego hay que implementar. Todo depende de los hipervisores que se estén usando, basta con clonar esa maquina virtual o pasar de una máquina física a una virtual.

Recuerden, sea cuál ser el servidor, el servicio, las configuraciones, las librerías, etc. lo mejor que podemos hacer es probar siempre primero en su entorno de desarrollo siempre. Con esto podemos evaluar su comportamiento y luego planificar su implementación en su entorno de producción.

Llevándolo un poco más a la práctica, por ejemplo, un buen diseñador web puede crear un nuevo estilo para una web desde su entorno de desarrollo, ver el comportamiento de ese estilo en diferentes navegadores, realizar las optimizaciones, etc. Lo mismo puede hacer un administrador de sistema, cuando por ejemplo debe migrar a una versión reciente de WordPress, es muy simple montar un LAMP, importar la base de datos extraída del entorno de producción y probar y actualizar el sistema WordPress, hacerlo una o varias veces o dejar que nuestro compañero aprenda sobre ese mismo escenario.

Las posibilidades hoy por hoy son infinita,  la verdad que les aseguro que se van a ahorrar muchos dolores de cabeza.

Saludos!

24 de septiembre de 2013

Por qué recomiendo crear HOWTO y publicarlos

Todos en algún momento, los que nos dedicamos a la administración de Servidores y la Seguridad, generalmente vivimos leyendo, a diario, además de noticias, tutoriales, webcast, papers y howto de como un problema puede ser resuelto utilizando alguna herramienta, como hacer hardening de un sistema, como configurarlo, optimizarlo, etc.

El hecho de recomendar la creación de HOWTO y publicarlos, es un principio básico de todos, en primer lugar la falta de memoria que con el paso del tiempo tenemos todos y que cuando queremos volver a reproducir aquellos que hicimos tenemos que recopilar nuevamente toda la información, por otro lado, crear un Howto nos ayuda a entender todos los temas en su profundidad y ver aquellos detalles que para nosotros puede ser algo habitual pero para un documento no lo es.

Por otro lado publicando nuestros Howto y compartiéndolo en cualquier formato, estoy más que seguro que vamos a estar colaborando con nuestros compañeros a solucionar su problema particular, e indirectamente vamos a estar promocionando nuestra marca personal, demostrando nuestras cualidades, conocimientos y aptitudes.

Por esta razón, los Howto no solo nos sirve a nosotros mismos para refrescar un conocimiento ya adquirido sino también a todas aquellas personas con esa misma problemática.

Un muy buen sitio para ver muchos Howto es http://howtoforge.com donde van a encontrar todos los COMO para el universo de los servidores GNU/Linux.

Por eso los animo a todos a crear sus propios Howto sobre cualquier tema que con un poco de difusión y buena redacción va a quedar en la memoria de muchos.

Saludos!

7 de agosto de 2013

Experiencias aprendidas al implementar Squid3 y Active Directory

Lo que les voy a comentar en las siguientes líneas no va a ser un tutorial sobre como integrar SQUID3 y Active Directory, aunque quizás más adelante lo escriba, simplemente quería comentarles mi experiencia al unir estas tecnologías como SysAdmin.

Antes de ponernos a trabajar, lo primero que hicimos fue evaluar todas las alternativas que vimos que existían en el mercado, la idea siempre fue utilizar la gran base de datos de usuarios de Active Directory registrados en un dominio Windows 2012 y utilizarlos para mantener un control en los accesos y abusos a Internet, de esa forma nos aseguramos de no dar usuarios diferentes, contraseñas distintas, etc.

Entre las alternativas evaluadas encontramos bajo servidores GNU/Linux Zentyal y todos sus servicios asociados, por otro lado encontramos uno similar llamado Artica, estas se caracterizaban por tener prácticamente todo el software pre-instalado, con lo cuál solo quedaba configurar algunos parámetros y comenzar a administrarlos en un entorno web, mucho más amigable para los administradores.

Esto fue así que comenzamos por instalar Artica, probarlo por algunas semanas, comprender su funcionamiento y pasarlo directamente a producción. Si bien Artica esta basado en Debian, la verdad es que tiene muchas modificaciones incluyendo su Fronend para administrarlo.

Y en un momento, pasó lo que uno no quiere que pase, Luego de una actualización o quizás un parámetro mal configurado de un momento a otro lo teníamos off.line al servicio por errores que en el apuro y quizás desconocimiento de la distribución no encontrábamos.

Entonces de aquí nuestro primer gran error, Utilizar y luego implementar en producción sistemas que no conocíamos solo por satisfacer una función.

Lo siguiente fue creer y fiarnos de la estabilidad de ese sistema que no conocíamos bien pero que era fácil administrarlo.

Desde ya Artica y Zentyal son excelente producto y recomiendo que los descarguen, pruebe e implementen.

Para solucionar esto, se decidió implementar Debian 7.1 Wheezy que es el más estable hasta la fecha, Squid3, Kerberos y Samba. Luego de unas semanas de fucionar estas tecnologías logramos sincronizar nuestro nuevo servidor con los dominios, autenticación por Kerberos, instalación del proxy SQUID3 y finalmente la implementación de los usuarios de Active Directory en el proxy, de esta forma podemos formar nuestras propias ACL de squid simplemente formando grupos en la administración de Active Directory.

Ahora bien, que ganamos con todo esto?


En primer lugar, utilizar y administrar un sistema que si es conocido por el equipo, en modo consola y de la manera más rustica pero en definitiva teniendo el control de la situación en todo momento.

Por otro lado utilizando el mismo servidor ganamos muchísimo ahorro de consumo en los recursos, por alguna razón Artica nos demandaba muchos más recursos en memoria, disco y procesador.

Por otro lado, pudimos ver y aprender como integrar estas tecnologías, ver de cerca realmente como crear nuestras listas de control de acceso, permisos, aceleración a Internet, etc.

Al final del días mi recomendación es NO utilizar aquel servicio que promete mucho y que es simple de administrar, busquen en sus conocimientos aquello que conocen que pueden manejar y llévenlo al extremo, y solo de esa forma se van a dar cuenta que tener el control sobre lo que pasa en su servidor no tiene precio.

7 de junio de 2013

Como crear un reporte de #NMAP

El otro día me encontré auditando la red, en búsqueda de nuevos servicios activos, y para ello nada mejor que utilizar nmap para hacer el barrido completo de todo, reconociendo puertos, identificando Sistemas Operativos, etc.

Figura 1: Logo nmap

El reporte final de consola es de lo más descriptivo, sin embargo necesitaba pasarlo a un informe y fue allí cuando vi que es posible crear un archivo XML como resultado de toda nuestra consulta, simplemente especificando su archivo de salida con el flag -oX

$ nmap -sV -T4 -O -F --version-light 192.168.4.0/25 -oX servicios_red.xml

Entonces hasta aquí, una vez que finalice el barrido de toda la red, identificando las estaciones de trabajo, puertos activos, SO, etc. todo lo va a exportar a un archivo servicios_red.xml para el ejemplo, ahora solo queda transformar este archivo en html.

En la documentación de nmap propone varios herramientas, a mi la primera que utilicé realmente me pareció muy simple y se llama xsltproc.

$ apt-get install xsltproc

De esta forma transformamos el archivo xml a html para terminar nuestro informe.

$ xsltproc servicios_red.xml -o servicios_red.html

Figura 2: Ejemplo de reporte HTML generado por nmap

A poner en práctica esta opción de nmap y será hasta la próxima.

Saludos!

22 de noviembre de 2012

Google Hack: Descubriendo archivos en ownCloud

Retomando la búsqueda de nuevos dorks en Google me encontré con algunos archivos y directorios interesantes que la gente suele subir a ownCloud.


ownCloud es un software para montar servidores Cloud privados, al buen estilo Dropbox, ya hace un tiempo largo estaba jugando con esta aplicación, en donde su instalación y puesta a producción es tan simple como instalar un CMS convencional.

La particularidad de ownCloud es que nos permite montar en Lan o Wan un servicio muy útil y bastante rápido para lograr sincronizar nuestros archivos, directorios, agenda y calendario.

La verdad es que podríamos hablar y escribir unos cuantos párramos más sobre las bondades y beneficios que nos provee no solo tener una nube privada bajo nuestro control sino también la utilización de ownCloud, pero la realidad es que por Internet está toda la información.

La idea de este dork es ver que ya se están publicando información sensible de las cosas que se suben a ownCloud, tan simple como realizar esta pequeña búsqueda.

inurl:"/?app=(files | media | calendar | contacts | gallery)" intitle:"ownCloud"



Saludos!

26 de octubre de 2012

Web Hacking- Attacks and Defence

Ayer a la tarde, la comunidad de seguridad Segu-Info compartió un enlace fantástico de un Libro que se encuentra en línea llamado "Web Hacking- Attacks and Defence" de Stuart McClurem, Shreeraj Shah y Saumil Shahsi. Donde se expone un completo ABC sobre los ataques y defensa que podemos llevar a cabo para proteger nuestras web y las buenas prácticas en programación.

"Si aplica las lecciones que ofrecen estos consultores de Foundstone, los atacantes van a tener que ser mucho más creativos y trabajar mucho más duro para romper la seguridad de su sitio."


Enlace | Web Hacking- Attacks and Defence

16 de mayo de 2012

7 parámetros para asegurar SSH

SSH es el protocolo más utilizado por los administradores para gestionar sus servidores de forma remota y segura.

Por defecto al momento de instalar ssh en el servidor, viene un algunos parámetros de configuración que podemos ir modificando para incrementar la seguridad sobre este servicio.

Para ello les propongo editar el archivo de configuración sshd_config que se encuentra en el directorio /etc/ssh para modificar los siguientes parámetros:

1 ListenAddress 192.168.0.1

Haga que ssh escuche solo la interfaz dada, sólo en un caso de que haya más de uno (y no necesite un ssh disponible sobre éste) o que en un futuro agregue una nueva tarjeta de red (y no necesite una conexión desde ssh en ésta).

8 de mayo de 2012

Fingerprinting en Wordpress: Parte IV

Hoy les propongo retomar el ejercicio de copilar información que nos brinda los Sistemas WordPress, pero en esta ocasión vamos a buscar información sobre el servidor que atiende esta pagina web.

WordPress es un CMS de tipo multiplataforma como gran característica, programado en PHP, sabemos que todos o por lo menos la gran mayoría de los servidores Web que atienden paginas HTTP lo hacen por su puerto 80, la idea es utilizar una herramienta como telnet para que el mismo servidor nos brinde esa información.

15 de abril de 2012

Google Hack: Servidores web con Apache


Y es que las arañas de Google no piden permiso para indexar lo que sea en la web, y por supuesto los “administradores” tampoco se privan de sacar las páginas innecesarias de sus servidores.

Es que con una pequeña búsqueda en Google, podemos ver como más de 68.000 administradores se olvidaron de eliminar la pagina de prueba que el servidor Apache crea al momento de la instalación.

intitle:"Test Page for Apache"

9 de abril de 2012

Como evitar listar los directorios en Apache2

Yo creo que si nos ponemos de acuerdo entre todos llegamos a la conclusión lo inseguro que es la web, mucho más cuando montamos nuestros propios servidores web, siempre tenemos que estar alerta antes intrusiones y estar pegados a los archivos log, por lo menos eso es lo que intento hacer desde mi experiencia.

Muchos de los problemas de inseguridad está dado por la falta de experiencia de los programadores, cuando realizan sus validaciones o concatenan sus consultas SQL y donde los posibles atacantes pueden llegar a tomar partido de esa situación. Pero muchas veces el problema puede estar del lado de los administradores de sistemas al no chequear bien los parámetros de configuración de esos servicios.

Hoy por ejemplo estaba viendo un archivo en formato .flv desde la web, cuando yo se que es posible descargarlo y poder verlo desde mi celular o directamente en otro momento, entonces realmente es muy simple conseguir la URL del archivo y descargarlo con wget. Cuando por esas cosas de la vida se me ocurre comenzar a escalar algunos directorios y me doy con que es posible navegar en los directorios del servidor sin ninguna restricción, con lo cuál encotré que había muchos más videos, archivos pdf, imágenes, etc.

30 de marzo de 2012

Google Hack: Identificando servidores XAMPP


Sin duda XAMPP, ese paquete de software preconfigurado que podemos instalar en un servidor web, es una solución extraordinaria para servidores en producción pero muchas veces requiere de ciertas configuraciones de seguridad para terminar de dejarlo en un servidor de producción.

Nuevamente la pereza de los administradores relajado ponen en riesgo y compromenten al servidor dejando la posibilidad de acceder al panel de configuración de XAMPP y todo por una simple búsqueda en Google.

inurl:\"/xampp/index.php\"



Como pueden ver en la imágen más de 85.000 servidores que están utilizando XAMPP como servidor web, seguramente con bases de Datos MySQL y php/perl/python como es un clásico en este paquete.

Entradas populares