Información blog

Linux, tutoriales, noticias, sistemas, redes y seguridad informática, entre otras cosas.

sábado, 28 de marzo de 2015

apt-get o aptitude. ¿Cual usar?

Todo aquel que haya usado una distribución basada en debian ha usado apt-get al menos una vez en su vida. Tal es la costumbre que muchos hemos adoptado que cuando vemos a otros usar el comando aptitude no entendemos por qué usa ese en vez de el clásico apt-get, más aún cuando a primera vista hace exactamente lo mismo; aunque la verdad es que hay algunas diferencias entre éstos.



Aptitude es una versión mejorada de apt-get que posee una interfaz gráfica que permite instalar los paquetes de forma más intuitiva que la consola. En cambio, si nos basamos únicamente en la consola, la diferencia entre ambos disminuye notablemente, pero aún así siguen existiendo diferencias. Algunas más importantes que otras. Las diferencias entre aptitude y apt-get son las siguientes:

1. La más importante es que aptitude, a diferencia de apt-get, es capaz de remover paquetes rotos y/o obsoletos de forma automática. Eso es muy útil cuando se realiza una actualización de un servicio que deja paquetes obsoletos por ahí colgados que pueden dar problemas. Con apt-get sería necesario realizar un apt-get autoremove para realizar la limpieza.
2. En apt, para actualizar se usan apt-get upgrade y apt-get dist-upgrade. En aptitude se usa aptitude safe-upgrade para lo equivalente a apt-get upgrade, y aptitude full-upgrade para lo equivalente a apt-get dist-upgrade. Gracias al punto 1 que acabo de mencionar, aptitude es capaz de hacer una actualización limpia que no da problemas con paquetes rotos y/o obsoletos.
3. Cuando se realiza una actualización con apt-get; en caso de crear un conflicto de paquetes no te permite instalar el paquete y punto; Con aptitude te pregunta si estás seguro de querer instalar el paquete que te va a generar conflictos. Esto no lo veo especialmente útil, pero para algunas ocasiones puede ser necesario.
4. Para realizar una búsqueda, se solía usar apt-cache search; en aptitude se usa directamente aptitude seach.
5. Aptitude incluye más opciones que apt-get

Aunque apt-get install sigue siendo muy útil en la mayoría de los casos muy usado. Las posibilidades ofrecidas por aptitude no pueden ser desestimadas y aunque es obvio que la primera opción va estar presente durante mucho tiempo, probablemente no sea mala idea tener en mente usar aptitude con expectativas al futuro. De momento, para realizar una instalación o desinstalación, es prácticamente indiferente usar una cosa u otra; En cambio para una actualización (especialmente cuando se actualiza de una versión de sistema operativo a otra) puede ser mejor usar aptitude para evitar que se queden paquetes obsoletos que después nos den problemas, aún cuando no se tiene tanto control de lo que se va desinstalando del sistema.


Conclusión

Todo es cuestión de gustos y cada uno tiene la libertad de escoger cualquiera de los dos métodos. Debian recomienda usar pptitude para gestionar mejor las dependencias; otros dicen que prefieren apt debido a que te ofrece mejores búsquedas y porque te da mayor control de lo que se instala y desinstala... Yo personalmente prefiero aptitude porque me facilita muchas cosas, pero cada uno puede escoger el que le sea más cómodo.

Saludos.

miércoles, 25 de marzo de 2015

Instalando y configurando Proxmox

Proxmox es un entorno de virtualización  libre, basado en KVM, muy conocido entre los amantes del Open Source que funciona bajo el sistema Debian. Aún siendo un software que se puede descargar gratis (a diferencia de otros que suelen ser más conocidos) se trata de una solución muy completa que puede equipararse a la competencia y que en caso de ser necesario te ofrece la posibilidad de pagar una tarifa que te permite tener soporte técnico para poder solventar cualquier incidencia relacionada con la virtualización; Al ser una herramienta muy completa que puede usarse tanto en entornos personales cómo profesionales, es interesante probarla cómo alternativa a los habituales virtualbox y vmware, y la verdad es que estoy satisfecho con lo que he probado hasta el momento y no he echado en falta ninguna funcionalidad en este sistema.

Proxmox ofrece la opción de descargar una ISO especialmente diseñada para que simplemente instalándola se obtenga el entorno de virtualización ideal, con lo que lo mejor es aprovechar esa posibilidad y descargar la iso aquí. El proceso de instalación es muy sencillo y la interfaz gráfica de la instalación es más depurada que antes, la cual empieza mostrando la siguiente pantalla:


En la gran mayoría de los casos habría que escoger la primera opción que es la seleccionada por defecto, la cual nos trasladaría al asistente de instalación en el que el primer paso que tenemos que hacer (aparte de leer los términos y condiciones) es escoger el disco duro en el que deseamos instalar el sistema en cuestión:


Tras realizar dicha selección pasaríamos a la selección del idioma en la cual simplemente habría que escoger el deseado y pasaríamos a la selección de una contraseña. Esta contraseña es muy importante pues va a salvaguardar la máquina virtual (y todo su contenido) con lo que hay que evitar a toda costa el uso de contraseñas cortas y/o sencillas; A poder ser una contraseña alfanumérica y de una longitud mínima de 7 caracteres.


Ahora sólo quedaría un paso: La configuración de los parámetros de red. En caso de que el servidor recibiese ip desde un servidor DHCP aparecería todo configurado por defecto a falta de poner el Hostname que uno desee. En caso de que no hubiese ninguno debido al motivo que sea, habría que configurarlo a mano, lo cual requeriría nociones básicas de redes LAN. En caso de no poseer dichas nociones sería interesante acceder aquí antes de continuar.



Tras concluir la instalación en cuestión, ya tendríamos el entorno preparado para usarse, pero antes de nada hay que analizar bien qué máquina virtual queremos añadir y cual va a ser su función. Uno de los errores más comunes a la hora de instalar un nuevo entorno virtualizado es el dimensionamiento de éste: En el mayor de los casos se escoge un tamaño de disco duro demasiado grande o una reserva de ram excesiva, haciendo que se desaproveche la máxima capacidad de entornos virtualizados simultáneos que se pueden llegar a tener; por ello lo más recomendable es analizar qué tipo de escenario es: ¿Qué servicios alojará y cuantos? ¿Irá almacenando contenido progresivamente? Una vez se tengan claro estos puntos se procedería a instalar la máquina virtual.

Para dicho propósito, proxmox posee una interfaz web bastante amigable que te permite gestionar con facilidad las diferentes máquinas; Para acceder a dicha interfaz sólo habría que escribir

https://ip_servidor:8006

En mi caso por ejemplo https://192.168.1.10:8006, lo cual mostraría algo cómo ésto:



Al loggearse con las credenciales adecuadas, aparecerán una serie de opciones a elegir; entre éstas hay una llamada create VM, ésta es la que usaremos para crear la maquina virtual que deseemos:


Y sólo tocarían seguir los pasos que te va indicando. El primero simplemente hace referencia al nombre de la maquina. El segundo paso se basa en la selección del sistema operativo. En caso de ser Windows te muestra todos los sistemas operativos disponibles perfectamente diferenciados entre sí, en cambio, si se quiere usar una distribución de Linux que no sea Solaris, es muy importante saber si se va a usar una versión actual o una bastante antigüa, eso es debido a que a la hora de elegir una de las opciones hay que especificar si va a usar un Kernel 2.4 o uno entre el 2.6 y un 3.X; En caso de escoger un sistema operativo bastante reciente indudablemente escoger el la versión entre 2.6 y 3.X:


La parte del CD/DVD consiste en elegir la ISO. Se puede escoger una ISO almacenada en el equipo, un CD físico introducido en la unidad de CD/DVD o  simplemente no escoger ninguna de dichas opciones:


Con respecto al disco duro cada uno debe de escoger el tamaño de disco deseado según sus necesidades, y especialmente es importante conocer qué tipo de disco duro se tiene SATA,IDE o SCSI. Lo más común suele ser que se tenga un disco SATA, a menos que se tenga un disco duro muy antiguo.


Para la CPU no sería necesario tocar nada; Con dejar los valores por defecto bastaría, especialmente si no se tienen conocimientos de éste tema. Cómo mucho recomiendaría poner dos núcleos (cores) para sistemas operativos que tengan que soportar una carga de trabajo considerable:


Ahora tocaría el turno de escoger la cantidad de RAM que queremos asignar al sistema operativo. Tal y cómo he dicho antes es uno de los puntos más importantes a la hora de crear una máquina virtual. Tenemos para escoger un tamaño fijo de memoria o un rango automático de memoria. Yo personalmente recomiendo usar un tamaño fijo para tener un mejor control de los sistemas operativos, pero cada uno debe de ver qué es lo que más le conviene.


El penúltimo paso consistiría en cómo queremos que la máquina se comunique a nivel de red. Es decir; Obviamente la máquina virtual carece de tarjeta de red física, con lo que debe de obtener las propiedades de red de la tarjeta de red física instalada en la máquina. Poseemos dos métodos de comunicación: Bridged y NAT. Bridged equivaldría a tener un nuevo equipo físico con su propia dirección ip mientras que NAT sale a internet emulando la misma ip que la del propio Proxmox. Para este tipo de entornos suele ser recomendable usar Bridged.


El último paso simplemente consiste en verificar que tenemos todo a nuestro gusto antes de confirmar la creación de la máquina virtual. En caso correcto ya tendríamos que clickar Finish y ya tendríamos la máquina virtual lista para ser usada.

Saludos cordiales.

lunes, 23 de marzo de 2015

grep, egrep y fgrep. ¿Qué diferencia hay entre éstos?

Grep es una de las herramientas más usadas en el mundo del mundo del software libre. Cualquiera, desde el principiante que empieza a jugar con la consola, hasta el más veterano, usa esta herramienta casi sin darse cuenta. ¿Quien no ha escrito alguna vez ls -la |grep "lo_que_sea"? Para aquel que este concepto le sea ajeno; grep es una herramienta que utiliza expresiones regulares para realizar consultas. Ésto es realmente útil cuando te encuentras con una gran variedad de archivos y sólo desea visualizar aquellos que tengan un patrón en particular: una extensión en concreto, que comiencen sólo por una letra que nosotros queremos, etc...



Dicha herramienta viene de forma nativa en todas las distribuciones Linux, y es generalmente usado en la consola cómo si fuese un comando o un parámetro. En caso de ir cómo comando se suele usar para realizar un filtrado general de todo lo que va encontrando. Por ejemplo para buscar todo lo que contenga la cadena que nosotros deseemos habría que poner:

grep "lo_que_sea" *

El * significa que busca todos los archivos que se encuentran el posición actual. El resultado que mostraría todos los ficheros y directorios que contengan el nombre "lo_que_sea" y todos el contenido "lo_que_sea" que haya en los ficheros.

Si se quisiesen buscar los archivos que NO contengan la que se ha introducido, habría que escribir añadir el parámetro -v tal que así:

grep -v "lo_que_sea" *


Si probáis el resultado de estos dos comandos, veréis que muestra todo de forma muy detallada y que busca incluso dentro de los ficheros, lo cual puede ser útil a veces, pero otras veces sólo nos interesa conocer el nombre de los ficheros y/o directorios sin detalle alguno, ya que con grep a secas hay demasiada información innecesaria. Debido a dicha necesidad existe el parámetro -l.


grep -l "lo_que_sea" *

Imaginemos que poseemos serie de patrones que hemos almacenado en un fichero y que queremos usar esos patrones para realizar una consulta en otro fichero. Es decir tenemos un fichero por ejemplo con tres líneas: la primera pone carne, la segunda pescado y la tercera verdura. Queremos ver si hay líneas en otro fichero que posean alguna de esas tres líneas; el parámetro -f nos permite hacerlo:

grep -f fichero_patrones.txt fichero_a_consultar.txt

Por último está el parámetro -r; el cual toma en cuenta el contenido de los directorios para realizar las búsquedas. Éste viene muy bien si nos encontramos en una ruta que contiene muchas carpetas y queremos revisar éstas sin tener que entrar dentro de éstas una por una. En algunas versiones puede que -r no funcione y tenga que usarse -F en su lugar:

grep -r "lo_que_sea" *

Ahora bien, aún cuando esto es muy útil, lo más común suele ser que lea la un comando introducido anteriormente y filtre el resultado. Para ello se introduce el comando deseado y se le añade |grep (parámetros) "lo_que_sea". En caso de querer usar éste método para grep, hay que tener en cuenta que no se puede usar el parámetro -l .Pongamos cómo ejemplo el famoso ls y cómo parámetro a buscar, todo aquello que empiece por a:

ls |grep "^a"

o todo aquello que contenga una a:

ls |grep a

o todo aquello que no contenga una a:

ls |grep -v a


o una expresión más compleja del tipo:


ls |grep -v "ae*" --> Esto sería lo mismo que decir que consulte todo aquello que no empiece por a seguido de una e más cualquier carácter o caracteres (entre uno e infinito).

Con esto uno tendría conocimiento sobre grep y en la mayoría de los casos, sería suficiente. Pero no siempre. Hay veces que uno se ve en la situación de que por la necesidad de la situación o porque se lo exigen, tiene que usar variantes de grep, variantes cuyas diferencias con el grep original son ligeras, pero significativas. Las variantes más famosas son egrep (Enhanced grep) y fgrep (Fixed-string), y aunque lo más común es usar el grep original, sería un error desestimar estas dos opciones.

Egrep


Comencemos con egrep. Esta variante es una versión más completa que el grep original, que mantiene las funcionalidades originales y además le añade unas nuevas. Esta herramienta es muy útil para realizar consultas avanzadas que grep por sí sólo no es capaz de realizar. Egrep es lo equivalente a grep -E, el cual no he explicado antes para tener la explicación mejor estructurada. Egrep acepta algunos símbolos que grep de por sí no acepta; Revisemos cada uno de éstos:


+ --> El carácter que le precede debe de coincidir una vez o más en la busqueda: egrep "poll+" fichero o directorio.

? --> El carácter que le precede es completamente opcional y coincide al menos una vez; Eso viene bien si por ejemplo se desea consultar un patrón y queremos que el último carácter sea cualquiera ya sea que exista o no, tal que así: egrep "poll?" fichero o directorio.

| --> Permite poner varios patrones de búsqueda tal que así egrep "pollo | pavo" "fichero o directorio". Esto buscaría todo aquello que coincidiese con pollo o pavo.

{} --> El carácter que le precede a este símbolo debe de aparecer un número determinado de veces que debe de ser determinado entre los {}. También puede ponerse un rango de número de apariciones. Esto puede parecer lioso así escrito con lo que lo mejor es mostrar unos ejemplos en los que las letras n y m que voy a poner son números aleatorios. IMPORTANTE: n y m siempre son números.:

       {n} --> El carácter que le precede aparece exactamente n veces.
       {n,} --> El carácter que le precede aparece cómo mínimo n veces.
       {n,m} --> El carácter que le precede debe aparecer n veces cómo mínimo y m veces cómo máximo.

Unos ejemplo más especifico podría ser éste:

cat fichero |egrep "C{1,5}ambios" --> Buscara todo aquello que contenga la palabra ambios y que la letra que le precede sea la C que debe aparecer entre 1 y 5 veces.

Fgrep

"Fixed-string grep", conocido erróneamente por muchos cómo "Fast grep", es una variante más veloz que grep pero que cómo contrapartida sólo puede buscar cadenas fijas (sin expresiones regulares, sólo la cadena). Cuando sólo se usa una cadena cómo patrón de búsqueda no se nota mucha diferencia, en cambio si se usa un gran número de patrones la diferencia es muy significativa.

fgrep "hola" /etc/ --> Válido
fgrep -f fichero_patrones fichero_a_consultar.txt --> Válido y mucho más veloz que grep -f
fgrep "ae*" --> Inválido


Con esto espero que tengáis un poco más claras las diferencias fundamentales entre cada tipo de grep.

Saludos.

sábado, 21 de marzo de 2015

Guía rápida de rpm

Linux es un mundo lleno de diferentes sistemas, de diferentes "sabores" que hacen que cada uno pueda escoger aquel que más le guste con total libertad. Aún así, lo cierto es que en los últimos años es innegable que los sistemas basados en Debian han ganado mucha popularidad, haciendo que muchos usuarios nuevos y no tan nuevos opten siempre por éstos en vez de por otras alternativas cómo aquellas basadas en red hat. Eso no significa para nada que red hat o los sistemas basados en éste no sean útiles sino que los últimos años las distribuciones basadas en Debian, especialmente Ubuntu, han ganado muchos adeptos mientras que las basadas en Red Hat no han tenido tanta suerte.

Aún así Red Hat sigue siendo una gran distribución, y aunque es necesario pagar por ésta, hay varias distribuciones gratuitas basadas en éste estupendo sistema operativo que pueden ser muy interesantes, cómo por ejemplo CentOS. Además, nunca se sabe donde se puede encontrar uno de estos sistemas, con lo que siempre es interesante tener nociones de cómo funcionan estos paquetes.



RPM (Red hat Package Manager) es un gestor de paquetes desarrollado por Red Hat y que luego ha sido adoptado por distribuciones basado en éste. Se basa en comandos, una base de datos y paquetes en formatos rpm. La base de datos se guarda en /var/lib/rpm y contiene toda la información de los programas instalados, incluyendo sus versiones, ficheros y dependencias. Por otro lado, los paquetes rpm poseen la siguiente estructura:

nombre-versión-edición.arquitectura.rpm


Para tratar paquetes de este tipo se usa siempre el comando rpm junto con la añadidura de un parámetro. El parámetro -i sirve para instalar un paquete:


rpm -i nombre-versión-edición.arquitectura.rpm


El parámetro -v actúa cómo verbose que sirve a modo de información mientras que el parámetro -h visualiza caracteres # para indicar el progreso del tratamiento de un paquete (por ejemplo el progreso de una instalación). En caso de que por ejemplo un paquete necesitase una dependencia para ser instalado, y no estuviese instalada, éste paquete no se instalaría. Un comando muy común para instalar y/o actualizar un paquete suele ser:


rpm -Uvh nombre-versión-edición.arquitectura.rpm

Para actualizar el paquete a una versión superior, habría que usar el parámetro -U, que movería los ficheros antiguos a una fichero llamado .rpmsave y serían sustituidos por los de la nueva versión. Si el paquete no tuviese una versión previa instalada, el paquete sería instalado y punto cómo si fuese un rpm -i. Para actualizar un paquete valdría por ejemplo:

rpm -Fvh nombre-versión-edición.arquitectura.rpm

Existe un parámetro parecido a -U, que es el -F; pero la diferencia entre uno y otro es que -F está limitado a solamente actualizar. Es decir que mientras que -U puede instalar y actualizar, -F es únicamente capaz de actualizar.

Por último estaría el parámetro -e, que sirve para eliminar un paquete. La diferencia, en este caso, es que solo basta con poner el nombre del paquete, con lo que el borrado del paquete sería:

rpm -e nombre

Ejemplos prácticos:

Para verlo más claro pondré como ejemplo el siguiente paquete:

skype-4.3.0.37-fedora.i586.rpm

Instalación: rpm -ivh skype-4.3.0.37-fedora.i586.rpm
Instalación/actualización: rpm -Uvh skype-4.3.0.37-fedora.i586.rpm
Actualización a secas: rpm -Fvh skype-4.3.0.37-fedora.i586.rpm
Eliminación: rpm -e skype

Espero que os sea útil.

Saludos.

miércoles, 18 de marzo de 2015

fail2ban, protección automatizada para Linux

En más de una ocasión he visto a gente con serios problemas para establecer filtros de seguridad en su sistema. En la mayoría de los casos es por desconocer la herramienta que manejan o por que no saben exactamente qué filtros usar. Actualmente por suerte tenemos numerosas herramientas que hacen esta tarea por nosotros y una de ellas me ha parecido muy interesante, ya que no solo no requiere muchos conocimientos sino que te ofrece una protección bastante sólida, que aunque no es infalible te puede proteger de la mayoría de las intrusiones más comunes. Se trata de fail2ban.


Fail2ban es una herramienta de software libre que destaca por tener unas funciones de protección básicas que luego se pueden expandir con facilidad escribiendo unas pocas líneas en unos pocos ficheros. Afortunadamente dichas líneas están muy bien documentadas en la propia página del proyecto y te señalan con gran exactitud que líneas hay que escribir y donde para poder proteger un servicio en concreto. El software en cuestión puede proteger ftps, accesos por ssh, servidores de correo, servidores web, servidores VPN, centralitas VOIP entre otros... y es tan sencilla de instalar cómo escribir:

apt-get install fail2ban(Debian)/yum install fail2ban (red hat)

Al ser un software cuya configuración se realiza directamente en sus ficheros sin mediación de ninguna interfaz gráfica, ocupa muy poco espacio y, aunque no lo parezca, es sencillo de configurar.

Antes de empezar a configurarlo hay que tener muy claro qué servicios hay que proteger ya que este software interactua con logs que emiten los servicios que quiere proteger y en caso de estar protegiendo un servicio que no está instalado, podríamos tener problemas. La lista de servicios que puede proteger son éstos y a modo de prueba voy establecer filtros para proteger uno de los programas más famosos dentro del sector informático: Apache. Apache es sin lugar a dudas el servidor web más usado del mundo y al estar siempre abierto al público, siempre es conveniente poner algunos filtros evitar sustos.

Para poner los filtros primero hay que tener unas nociones básicas sobre el programa en cuestión que son útiles tanto para este servicio cómo para cualquiera que se quiera proteger en el futuro. Lo primero que hay que saber, es que todas las configuraciones están alojadas en la carpeta /etc/fail2ban/. Esa carpeta aloja 4 elementos de vital importancia:

1. action.d: Carpeta que contiene las acciones que realiza el software tras encontrar algo que considera una intrusión. En un principio no es necesario configurar para que los filtros funcionen, pero en caso de tener unas necesidades muy personalizadas se pueden modificar algunos parametros de esta carpeta. Uno de las opciones más interesantes que ofrece esta carpeta es la configuración de fai2ban para que envíe un correo a una dirección en concreto al detectar una intrusión, pero para ello hay que tener el software sendmail correctamente instalado y configurado para que sea capaz de envíar correos.

2. fail2ban.conf: Fichero de configuración general del software: En éste fichero se configuran 3 parámetros. El nivel de log del sistema en el que se establece si quiere que los logs muestren simplemente información (valor por defecto) o por el contrario muestre avisos, errores o información detallada de todo (llamado debug). Esos niveles quedarían así:

           1 ERROR
           2 WARNING
           3 INFO
           4 DEBUG

El destino de esos logs también se configuran en este fichero, al igual que el puerto en el que escucha el servicio (recomendable no modificar este último valor)

3. filter.d: Esta carpeta almacena las expresiones de los logs que analiza para saber si la línea del log en cuestión se refiere a una intrusión o no. La carpeta tiene ficheros .conf y cada uno de éstos tiene en su interior las líneas que analiza en los logs. Si en el log apareciese una línea que coincidiese con lo que analiza uno de los ficheros que hay en filter.d, fail2ban tomaría las medidas pertinentes. Fail2ban almacena por defecto varios ficheros encargados de analizar (por ejemplo) ssh o apache.

4. jail.conf: Aquí se configura la gestión de filtros; es un fichero que tiene todo lo referente a los filtros y la gestión de éstos. El fichero se podría considerar que está compuesto por dos partes: La de configuración general y la de lo que yo llamo secciones. 

La parte de configuración general tiene tres parámetros muy importantes: bantime, maxretry y findtime. El bantime establecería durante cuanto tiempo se bloquea una ip atacante (en segundos). Por defecto viene con un valor de 600 segundos, un valor relativamente bajo que se podría modificar al gusto de cada uno. Cómo ayuda os informo de que 3600 equivaldría a una hora y 36000 a diez. Maxretry, establece el número de intentos máximos por defecto que se establecen en software, para que si se alcanzase el máximo de intentos, el sistema bloquease la ip atacante. Por último, pero no menos importante, está findtime:

Findtime no aparece por defecto en jail.conf, pero es muy interesante añadirlo ya que hace que se cuente el número de intentos de conexión dentro de un intervalo de tiempo. Me explico: Imaginemos que no tenemos puesto el parametro findtime y queremos autenticarnos en la página web que protege fail2ban y que tiene un límite de 3 intentos. Al no tener un findtime, si en cualquier momento llegasemos a fallar 3 veces (que no tienen que ser consecutivas, ni mucho menos), el acceso nos sería bloqueado aún cuando el primer intento fallido se realizó el 1 de enero, el segundo el 2 y el tercero el día 3. En cambio, con findtime lo que se consigue es establecer un periodo de tiempo que controla el número de intentos fallidos de conexión; Si por ejemplo se pusiese un findtime de 60 segundos, bloquearía al atacante sólo si realizase 3 intentos fallidos de conexión dentro de ese periodo de tiempo. Para añadir el findtime habría que escribir debajo de maxretry:

findtime= número de segundos

Por otro lado están las secciones. Las secciones son las que almacenan toda la gestión de los filtros: Una sección sería reconocida mediante la siguiente nomenclatura:

[Nombre-sección] --> Ejemplo: [apache]

Cada sección estaría compuesta de los siguientes puntos:


enabled --> Aquí se dice si se quiere tener habilitado el filtro de la sección o no. Solo hay dos posibles valores: true y false

port --> Aquí se establece el puerto que "vigila" el filtro. El puerto puede ser numerico o se puede poner el nombre del puerto en cuestión. En caso de no conocer bien los puertos o no acordarte de todos, puedes consultarlos entrando aquí.

filter -->Aquí habría que poner el nombre del fichero que está dentro de la carpeta filter.d. Tal y cómo he comentado antes, todos los ficheros de filter.d tienen la extensión .conf, pues aquí habría que omitir dicha extensión; es decir que si por ejemplo para esta sección se usase apache-auth.conf cómo fichero que va a encargarse de revisar los logs, habría que poner aquí solamente apache-auth.

logpath -> Aquí simplemente se pondría la ruta del log que se quiere revisar.

maxretry -> Aquí se cuentan el número de intentos que se pueden realizar cómo máximo al servicio que se está filtrando. Si se alcanzase el máximo de intentos, el sistema bloquearía la ip atacante. En caso de establecer un maxretry distinto al de la sección general, el maxretry de la sección tendría más prioridad.

Ahora que se poseen las nociones básicas de lo que compone fail2ban, tocaría habilitar apache para que filtre las intrusiones. Para ello habría que entrar en jail.conf y buscar las secciones: apache, apache-multiport,apache-noscript,apache-overflows; En todas éstas sólo habría que cambiar el parametro enabled a true, quedando tal que así:

  1. [apache]
  2. enabled  = true
  3. port     = http,https
  4. filter   = apache-auth
  5. logpath  = /var/log/apache*/*error.log
  6. maxretry = 6
  7. # default action is now multiport, so apache-multiport jail was left
  8. # for compatibility with previous (<0.7.6-2) releases
  9. [apache-multiport]
  10. enabled   = true
  11. port      = http,https
  12. filter    = apache-auth
  13. logpath   = /var/log/apache*/*error.log
  14. maxretry  = 6
  15. [apache-noscript]
  16. enabled  = true
  17. port     = http,https
  18. filter   = apache-noscript
  19. logpath  = /var/log/apache*/*error.log
  20. maxretry = 6
  21. [apache-overflows]
  22. enabled  = true
  23. port     = http,https
  24. filter   = apache-overflows
  25. logpath  = /var/log/apache*/*error.log
  26. maxretry = 2

Ahora sólo quedaría reiniciar fail2ban y ya tendríamos el filtrado preparado. Para saber que efectivamente tenemos los nuevos filtros implantado, solamente habría que escribir:

iptables -nvL

Con dicho comando veríamos todos los filtros que fail2ban ha implantado.

Añadiendo un filtro completamente nuevo

Los servicios más usados aparecen por defecto en la carpeta filter.d y en el fichero jail.conf, pero imaginemos que no es un servicio tan "popular" cómo el resto. ¿Qué habría que hacer ahí? En el listado de servicios que he mencionado anteriormente se puede acceder a la documentación que señala todo lo necesario para añadir nuevos filtros, pero es interesante entender el concepto.

En caso de querer añadir un nuevo servicio, habría que hacer dos cosas. La primera sería entrar en la página del proyecto para copiar el contenido necesario para el fichero que iría en la carpeta filter.d, y segundo modificar el fichero jail.conf para referirse tanto a los logs deseados cómo al nuevo fichero almacenado en filter.d. Pongamos por ejemplo el servicio Asterisk; Asterisk es uno de los servicios que el programa es capaz de proteger, pero no incluye la información necesaria por defecto para hacerlode la misma forma que lo hemos hecho con Apache.

Para este caso en particular habría que acceder aquí y copiar el contenido que explica a un fichero llamado asterisk.conf, el cual iría almacenado en filter.d. Por último habría que entrar en jail.conf y añadir las líneas necesarias para que los filtros funcionen; en este caso por ejemplo habría que añadir al final del fichero; cómo podéis ver sigue la misma estructura que la que he comentado antes con la diferencia de que añade una nueva línea :


  1. [asterisk-iptables]
  2. # if more than 4 attempts are made within 6 hours, ban for 24 hours
  3. enabled  = true
  4. filter   = asterisk
  5. action   = iptables-allports[name=ASTERISK, protocol=all]
  6.               sendmail[name=ASTERISK, dest=you@yourmail.co.uk, sender=fail2ban@local.local]
  7. logpath  = /var/log/asterisk/messages
  8. maxretry = 4
  9. bantime = 86400

Recordad que después de aplicar cualquier cambio hay que reiniciar fail2ban para que aplique los cambios.

Espero que os sea útil.

Saludos.

lunes, 9 de marzo de 2015

Modo Dios en Windows 7

En esta ocasión he optado por un post muy corto pero que más de uno puede encontrar útil. Aquellos que usamos Linux con regularidad cómo administradores, nos hemos acostumbrado a la libertad total que nos concede el usuario root (en Linux root es el equivalente a dios) lo cual nos hace sentir muy limitados cuando tenemos que tratar con entornos Windows.

En esta ocasión voy a explicaros cómo intentar tener el mayor control posible de Windows (dentro de sus limitaciones, recordemos que es un entorno privativo) creando una carpeta que nos va a dar control "total" del sistema. Dicha carpeta que nos haría ser "dioses" ha sido probada en Windows7, no pudiendo garantizar su funcionamiento en otras versiones.

Para lograr dicho objetivo simplemente habría que crear una carpeta con el siguiente nombre:


GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}


Al finalizar, se verá que la carpeta en cuestión cambia su nombre y aspecto, acabando así:


Ahora al entrar en dicha carpeta veremos que ofrece una gran variedad de posibilidades agrupadas en un sólo sitio, teniendo una mayor libertad de movimiento que antes.

Saludos.

viernes, 6 de marzo de 2015

Port knocking Linux

¿Alguna vez habéis pensado dificultar un poco el acceso al puerto SSH del servidor? ¿Algo cómo por ejemplo que se tengan que cumplir una serie de condiciones para abrir la "puerta" de acceso SSH? El port knocking puede ayudaros a cumplir dicho objetivo. Port knocking se basa en "tocar" algunos puertos (que obviamente están cerrados) en el orden correcto para abrir el paso por un puerto que antes estaba cerrado. Algo así cómo tocar la puerta en una secuencia determinada para que te abran ésta. 


Obviamente la puerta no quedaría abierta indefinidamente ya que en caso contrario con acertar una vez dicho puerto quedaría abierto para siempre. A continuación he puesto un script de ejemplo que explica el funcionamiento de dicho concepto. Dicho script es plenamente funcional y no habría problema alguno si se usase tal y cómo está (a menos que se quieran cambiar los puertos claro está). En este caso he hecho que se necesite una combinación de 3 "toques" para lograr tener acceso al puerto SSH.

Dicho método de protección no es perfecto y no debe de ser la base de la seguridad de un servidor, sino que debe de consistir una capa de protección extra a las medidas de seguridad ya implantadas; aún así, si que es recomendable implantarlo cómo medida de seguridad adicional para evitar los ataques aleatorios a servidores SSH que tanto se realizan hoy en día.


  1. #!/bin/bash
  2. ##SCRIPT DE PORT KNOCKING##
  3. #VARIABLES
  4. PUERTO1=10000
  5. PUERTO2=15000
  6. PUERTO3=20000
  7. PUERTOSSH=22
  8. SEGUNDOS=30000
  9. #Reglas de PortKnocking basado en tres puertos (10000, 15000, 20000)
  10. # Puerto 22 por defecto esta establecido a DROP
  11. iptables -A INPUT -p tcp --dport 22 -j DROP
  12. # Creación del segundo Knock
  13. iptables -N IN-KNOCK2
  14. iptables -A IN-KNOCK2 -m recent --name KNOCK1 --remove
  15. iptables -A IN-KNOCK2 -m recent --name KNOCK2 --set
  16. # Creación del tercer knock
  17. iptables -N IN-KNOCK3
  18. iptables -A IN-KNOCK3 -m recent --name KNOCK2 --remove
  19. iptables -A IN-KNOCK3 -m recent --name KNOCK3 --set
  20. # El mas sencillo, el primer KNOCK
  21. iptables -A INPUT -m recent --update --name KNOCK1
  22. # Que hacer en caso de cada knock
  23. iptables -A INPUT -p tcp --dport ${PUERTO1} -m recent --set --name KNOCK1
  24. iptables -A INPUT -p tcp --dport ${PUERTO2} -m recent --rcheck --name KNOCK1 -j IN-KNOCK2
  25. iptables -A INPUT -p tcp --dport ${PUERTO3} -m recent --rcheck --name KNOCK2 -j IN-KNOCK3
  26. # Finalmente abrimos el puerto para quien haya realizado la secuencia correcta
  27. iptables -A INPUT -p tcp --dport ${PUERTOSSH} -m recent --rcheck --seconds ${SEGUNDOS} --name KNOCK3-j ACCEPT

En este caso, para lograr acceder al puerto 22 habría que "tocar" primero el puerto 10000, a continuación el 15000, y por último el 20000; Dichos toques habría que hacerlos en el orden correcto y sin equivocarse en la secuencia; Con lo que por ejemplo se tocase el 10000, luego el 12000 y luego se tocasen correctamente los dos siguientes puertos, no se conseguiría tener acceso. En este caso en concreto el acceso estaría abierto durante 30000 segundos, pero es un valor perfectamente modificable.

Espero que os sea útil y que le podáis sacar partido a dicho concepto.

Saludos cordiales.

miércoles, 4 de marzo de 2015

Resetear permisos del contenido de un disco duro Windows 7

El otro día me encontré en la desagradable situación de que un disco duro externo, debido a algunas modificaciones que se fueron haciendo y la utilización del bitlocker de Windows, me impedía ejecutar cualquier tipo de contenido multimedia con Windows Media, diciéndome el siguiente mensaje:


Aún tras quitar el cifrado al disco duro resultaba imposible ejecutar los archivos, pareciendo que se habían quedado inutilizables. Tras indagar un poco, llegué a la conclusión de que había un problema de permisos y que era necesario reestablecer los permisos de los ficheros para poder ejecutarlos. Para ello primero opté por el método convencional, que se trataba de restaurar los permisos de un fichero en concreto, que aunque resulto ser exitoso, era muy poco práctico, ya que no permitía hacer la misma operación de forma global y necesitaba repetir el procedimiento en cada uno de los ficheros...

Al ver lo incomodo que era el tener que repetir lo mismo para cada fichero, revisé la posibilidad de restaurar los permisos en todo el disco y tras indagar un rato encontré una solución que requiere muy poco tiempo y que en mi caso ha sido muy efectiva. La contrapartida de dicha solución es que requiere el uso de la consola, cosa que a más de uno le puede dar respeto, pero puedo asegurar que los comandos que voy a mostrar a continuación no van a realizar ningún daño ni al disco ni al sistema. Esta demostración se realiza en Windows 7, con lo que si se quiere acceder a la consola en otra versión puede variar ligeramente el acceso a la consola:

Comenzamos clickando el botón de inicio y escribimos cmd, pero antes de presionar la tecla enter, os fijareis que en la parte superior aparece en la sección programas un símbolo con dicha nomenclatura, habría que hacer click derecho sobre dicha nomenclatura y ejecutarlo cómo administrador:




Puede parecer absurdo ejecutarlo cómo administrador en vez de la forma habitual, pero el ejecutarlo así nos asegurará que podamos ejecutar los comandos sin ningún problema. Con la consola de comandos abierta, tocaría escribir primero el siguiente comando:

takeown /f "letra disco":*

Allí donde pongo "letra disco:" sería la letra de la unidad en cuestión cómo G: por ejemplo. Supongamos que queremos aplicar el comando todos los ficheros de la unidad G:

Ejemplo: takeown /f G:*

El comando en cuestión hace que todos los ficheros de la unidad G, pasen a ser propiedad del usuario actual que ha ejecutado el comando; Con ello nos aseguramos de que cuando queramos resetear los permisos no nos salten alertas que nos impidan realizar la tarea en su totalidad.

Ahora que somos los propietarios de todo el contenido de la unidad G, nos desplazamos a dicha unidad en la consola escribiendo el nombre de la unidad en cuestión, en este caso G.

G:

Es muy importante estar dentro de la unidad cuyos permisos queremos resetear, ya que en caso contrario el comando que vamos a ejecutar a continuación no le afectaría. Estando dentro de la unidad, podemos resetear los permisos de TODOS los ficheros que están dentro mediante el siguiente comando:

icacls * /T /Q /C /RESET

La duración del proceso varía dependiendo del tamaño de la unidad y la cantidad de ficheros que hay dentro de ésta; puede parecer que no esté haciendo nada, ya que no muestra barra de progreso alguna, pero en realidad está trabajando internamente... Tras finalizar la espera, ya tendríamos el todo contenido del disco totalmente accesible, y el error mostrado al inicio de este post no debería volver a aparecer.

Espero que os resulte útil.

Saludos.

lunes, 2 de marzo de 2015

Análisis y medidas de defensa en una red local. Parte II

Continuando con el articulo anterior, voy a proseguir en este apartado de las posibles defensas que se pueden tomar contra algunos de los ataques más comunes en una LAN. En el apartado anterior hablé de las medidas que uno puede tomar contra el ARP spoofing y el port flooding y ahora hablaré las medidas que uno puede tomar contra otros dos ataques, uno de ellos especialmente conocido.


Detección y protección de ataques DOS/DDOS.

La popularidad de este tipo de ataques ha ido aumentando en los últimos años, habiéndose convertido en uno de los ataques más extendidos y populares actualmente. El ataque en sí es bastante "simple", pero su principal "virtud" es que dependiendo de la escala del ataque puede ser muy difícil de parar. Los ataques de DOS son conocidos cómo ataques de denegación de servicio (Denial Of Service) y consisten en mandar peticiones constantes a un servicio expuesto al público (generalmente una página web) y desbordarlo con tamaña cantidad de peticiones que luego, cuando un usuario que en verdad quiere acceder al servicio en cuestión, es incapaz de conseguirlo ya que el servidor se encuentra demasiado saturado atendiendo las peticiones enviadas por el atacante. Últimamente este tipo de ataques han evolucionado al siguiente nivel, al DDOS (Distributed Denial Of Service), y básicamente son iguales con la diferencia de que el ataque se realiza desde distintos puntos de información, haciendo el ataque mucho más agresivo (por el mayor volumen de peticiones al servicio) y más difícil de parar (hay que tratar de bloquear diferentes orígenes de forma efectiva). Una forma gráfica de expresar este tipo de ataques de forma simple sería algo cómo lo que muestro a continuación:




Estos ataques son tan agresivos, que por lo general, a menos que se tengan defensas contra estos ataques, enseguida se nota una bajada de rendimiento en el servicio en cuestión (por ejemplo una página web iría mucho más lenta) y dependiendo del volumen del ataque y de la capacidad del servidor, el servicio podría no estar disponible para cualquier usuario en cuestión de minutos, pareciendo que dicho servicio está caído; Además, en caso de tener un PC vigilando el tráfico que hay entre el servidor y el switch, y con un sniffer cómo, por ejemplo, wireshark; vería que el servidor está siendo inundado por peticiones:



Desde un servidor sería incluso más fácil, ya que con realizar el comando netstat -putan |grep "servicio" se vería que hay una cantidad exagerada de conexiones, pero en caso de no tener acceso al servidor, con wireshark se puede ver muy rápido que se está recibiendo un ataque de DOS.

La defensa contra este tipo de ataques es muy complicada: El bloquear la ip del atacante no basta, ya que el atacante estará usando ips falsas que en caso de que sean bloqueadas cambiarán con el fin de superar dicha barrera y el cerrar por completo el servicio atacado significaría que el atacante ha logrado su objetivo igualmente... Se trata de una situación muy complicada que por lo general se resuelve contactando con el ISP (Internet Service Provider). El ISP es la empresa con la que se ha contratado el servicio de internet y es la que tiene los mejores recursos para bloquear estos ataques; Otra opción es bloquear este ataque en el servidor, pero para ello se necesita que:

  • El servidor tenga bastantes recursos.
  • El volumen del ataque no sea demasiado grande.

De todas formas este típo de defensas tienen cómo contra que aunque se consigue mitigar el ataque, el ancho de banda es consumido por el susodicho, haciendo que la conexión pueda llegar a verse ralentizada. De todas formas es recomendable establecer defensas en el servidor para que en caso de ser atacado se pueda aguantar hasta que el ISP actue. Los tipos de ataque de DOS, aunque son parecidos entre sí, varían,  pero unas medidas de seguridad que se podrían implantar sin afectar a la flexibilidad y funcionalidad del sistema sería:
  1. Escribir el comando: sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1.
Este pequeño comando hace que se ignore todos los paquetes broadcast que reciba; Por lo general los dispositivos que reciban un paquete de broadcast responden con el fin de que puedan ser identificados; Mediante la desactivación de respuesta a ese tipo de paquetes, se lograría cierta protección contra aquellos que quieran saturar al servidor con paquetes broadcast constantemente.

      2.  Escribir el comando: sysctl -w net.ipv4.tcp_syncookies=1

Este comando evitaría que el servidor no se viese saturado por paquetes SYN enviados por el atacante (tal y cómo se ve en la anterior imagen), y así, en caso de que se recibiese un ataque de peticiones SYN ,que nunca se resuelven debido a que la ip de origen es falsa, el servidor sería capaz de evitar dicha saturación.

    3. Establecer filtros especiales para evitar la saturación de peticiones desde un origen en concreto para ciertos servicios concretos:

  1. # Establecemos que los paquetes de typo syn que sean NEW provengan de la misma ip un máximo de 10 veces.
  2. iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-upto 10 -m state --state NEW -j ACCEPT
  3. # Hacemos que las conexiones de tipo ESTABLISHED,RELATED vayan normal
  4. iptables -A INPUT -p tcp --dport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT
  5. # El resto de peticiones al 80 se deniegan
  6. iptables -A INPUT -p tcp --dport 80 -j DROP

En este caso lo he puesto para proteger el puerto 80 (web), pero se puede aplicar a cualquier puerto en concreto. Esto hace que el número de nuevas peticiones desde un mismo origen no sea mayor de 10. Este filtro no aceptaría a las conexiones establecidas, sólo a las nuevas, haciendo que la navegación de un usuario normal no se vea afectada.

En caso de querer añadir medidas adicionales un servicio web cómo apache (recordemos que estamos haciendo todo con un entorno Linux),  sería recomendable instalar el módulo mods-evasive en apache. Para ello habría que hacer lo siguiente:


sudo apt-get install libapache2-mod-evasive

a2enmod mod-evasive


Con esto ya estaría instalado y preparado el modulo, pero para que nuestra página sea capaz de usar dicho módulo habría que entrar en el fichero apache2.conf y añadir lo siguiente al final del fichero (aquello que tiene # al principio son comentarios que explican qué es cada opción):

#DOSHashTableSize va por defecto con ese número
#DOSPageCount el número de veces que se puede conectar uno a la misma página en 1 segundo
#DOSSiteCount el número de veces que se puede conectar uno al mismo sitio en 1 segundo
#DOSPageInterval intervalo de tiempo del DOSPageCount
#DOSSiteInterval intervalo de tiempo del DOSSiteCount
#DOSBlockingPeriod Tiempo que mantiene el bloqueo
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 5
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 300
</IfModule>


Cómo recomendación general para cualquier servidor que esté de cara al público, sería el poner el servidor que aloja dicho servicio en una DMZ (Zona Desmilitarizada); La DMZ es una zona que estaría más expuesta al público que el resto de elementos de la LAN, siendo objetos de distintos ataques mientras que el resto de elementos posee medidas de seguridad adicionales que los protegerían de dichas intrusiones; Algo cómo esto:




De todas formas, tal y cómo he dicho al principio, si aún con estas medidas se ve que el servidor está muy saturado por la denegación de servicio, lo mejor es contactar con el ISP que podrá adoptar medidas extra para paliar los efectos de éste.


Detección y protección de ataques DHCP spoofing:

Estos ataques consisten en la suplantación de un servidor DHCP (Dynamic Host Configuration Protocol). La mayoría de las personas no son conscientes de ello pero en el día a día se usa este servicio de forma implicita en sus hogares. Todo router posee un servidor DHCP que hace que cuando uno enciende el ordenador y tiene el cable de red conectado al router, automáticamente posee conexión a internet sin tener que tocar ni configurar nada; Eso es debido a que el DHCP otorga ip de forma dinámica a todo los equipos que están preparados para lograr la ip de dicho modo. Por defecto todos los ordenadores están diseñados para lograr la ip por dhcp a menos que se le especifique lo contrario.

Los ataques de este tipo pasan desde sofisticadas herramientas a un simple servidor DHCP que se intenta adelantarse al servidor autentico. Para detectar esos ataques se puede usar un sniffer para ver que hay un servidor DHCP que trata constantemente de otorgar los datos de red a un equipo; En caso de tener controlada la dirección real del servidor DHCP es muy fácil distinguir si el servidor DHCP que está dando ip en la red es el real o no y una vez controlado dicho punto sólo habría que intentar bloquear la ip en cuestión o bloquear el puerto al que está conectada esa ip para que deje de intentar suplantar al DHCP original. 

La medida más efectiva para evitar estos ataque sería la implantación de un filtro en el switch que bloquease el puerto de origen 67 en todos los puertos de red que estén configurados para que se conecten los PCs de sobremesa y/o equipos que se sabe que jamás podrían actuar cómo servidores DHCP. 



El objetivo del DHCP spoofing es el mismo que el del ARP spoofing: Interponerse en las comunicaciones de la victima para controlar todo el tráfico que envía y recibe ésta; Al ser un ataque relativamente sutil de cara al usuario final, hay que andar con cuidado, debido a que las comunicaciones del usuario final podrían verse interceptadas sin que este se diese cuenta de ello.


Espero que os haya sido útil

Saludos