Categoría: Debian

Analizando tráfico con Netflow – pmacct – flowAnalyzer.

Además de usar LibreNMS en aaNetworks, desde hace tiempo tenía la idea de usar NetFlow [https://en.wikipedia.org/wiki/NetFlow], esta configuración está al borde de OverKill en un home network, pero qué más da!

 Flow Exporter: por el momento cuento con cinco equipos que cumplen con esta tarea, lo exportadores o probe como son mejor conocidos son los encargados de agregar los paquetes en flows y exportarlos al equipo central el cual se usara para hacer visualización de la información exportada.

Equipos cumpliendo esta tarea son:

zapp – Mikrotik RB493AH: RouterOS tiene la funcionalidad de capturar paquetes y enviarlos como flow ya sean v5, v9 o IPFIX, en mi caso está configurado para v9.

 

elzar – Ubuntu 17.04.

vul – Debian Jessie.

leela – Debian Stretch.

fry – Debian Stretch.

En el caso de Debian, existen varias opciones para tener la funcionalidad de PROBE, algunas son directamente en el kernel otras son aplicaciones que usan libcap, en mi caso me decidí por una aplicación llamada pmacct (ni idea como se pronuncia) la cual cuenta con un PROBE y muchas otras funcionalidades que en una entrada futura hablare de ellas.

Flow Collector: esta es la plataforma/aplicación responsable de recibir los flows que fueron generados en los PROBE, esta es la parte difícil, muchas de estas plataformas/aplicaciones son de pago. La razón, sencilla, los PROBE ya vienen en los routers asi que solo faltaría el Collector y dependiendo de la calidad del software que se use para colectar se verán los beneficios de tener NetFlow.

En mi caso he implementado una aplicación no tan conocida, tope con ella en un sub-reddit. flowAnalyzer es una combinación de varias aplicaciones las cuales forman el Colector y la aplicación de Análisis. Esta plataforma está basada en ELK, esta es la ventaja, luego que tenemos información generada en los probe importadas en un index de Kibana, podemos generar cualquier tipo de gráficos con información importada en el index.

En el caso de flowAnalyzer, los colectores son el producto del creador de la plataforma, estos colectores fueron desarrollados específicamente para esta tarea usando Python como lenguaje.

En esta tabla se pueden apreciar las versiones de flow soportadas y sus respectivos puertos.

 

Discover: esta es una sección típica de Kibana, aquí podemos ver casi en real-time todo lo que fue indexado y procesado por ElasticSearch y Kibana. Partiendo de este punto crearemos visualizaciones para luego crear dashboards.

La siguiente captura muestra todo el tráfico relacionado a la categoría Web que ha pasado por Vul.

 

Aventuras con BGP.

Cuanto tiempo!  Algunos me han preguntado que si ya no planeaba escribir más en el blog (no muchos, pero si me han preguntado.).

Por cuestiones de trabajo, poco a poco fui descuidando el blog a un punto que ahora veo que se han perdido imágenes de algunas entradas, eso me pasa por usar Dropbox como proveedor de contenidos. Eso es algo que puedo arreglar más adelante, ahora al tema de la entrada.

A mediados de 2016 pude notar que viarios participantes de dn42 estaban usando ASN públicos asignados por ARIN, que chulo no? así que comencé a investigar y termine adquiriendo un Numero Autónomo público. Para que se preguntaran algunos, la respuesta es que desde hace mucho tiempo tengo una adicción al routing a un nivel que en mi pequeña red de la casa estoy corriendo BGP + OSPF para distribuir las rutas internamente.

Después de varios meses de jugar con el ASN y cambiar todos los Debian + Quagga que tenían ASN privado (64635 – 64714) al nuevo y reluciente ASN público (207036), comenzar a anunciar asignaciones de IPv6 (ya casi todo esta dual-stack, yija!!!!), termine con una asignación /22 de IPv4.

Entonces, como esta aaNetworks al día de hoy con relación a networking?

https://aanetworks.org/

 

 

 

 

 

 

 

 

Se puede conseguir más información en BGP.he.net

http://bgp.he.net/AS207036

Site-to-Site con Vyatta y OpenVPN en Debian.

Hoy toca uno de Networking, como el titulo lo dice, esto no es solo de Virtualización!

Si como yo tienes varias localidades (nah!! Son varios servidores Dedicados con VMs las cuales uso para pruebas) y las quieres administrar directamente como si estuvieran conectadas en una red corporativa y sin problemas de port-forwarding, aquí tengo “una solución” para eso.

Desde hace un tiempo no uso pfSense, por qué?  No me gusta OpenBGPd. Es algo lento en pfSense, esa es mi impresión. Además de eso, no creo que soportara una tabla full de BGP, en Vyatta actualmente en mi lugar de trabajo la tenemos en 2 servidores con Vyatta desde nuestro proveedor CLARO.

Bueno, lo de BGP será para otro post, ahora mismo para conectar nuestra localidad remota necesitaremos de un router que soporte OpenVPN en ambos lados, en mi casa tengo Vyatta y en el punto remoto un servidor Debian con OpenVPN instalado desde los paquetes. Necesitaremos los siguientes datos:

Red para el túnel: 10.45.252.252/30

Red en mi casa: 172.22.35.0/26

Red en punto remoto: 172.22.114.0/26

IP WAN en Vyatta-HOME: Dinámico (Gracias al DSL de CLARO)

IP WAN en Debian con OpenVPN: 173.208.168.10

Solo nos falta generar un key con OpenVPN para usarlo en este túnel:

openvpn –genkey –secret static.key

Con estos datos ya podemos configurar…..

En Debian con OpenVPN:

mode p2p          # modo peer to peer

proto udp           # protocolo UDP

lport 1194          # puerto local

dev-type tun     # tipo de interface, TUN porque sera en modo routing.

dev tun-home  # nombre de la interface que se vera en ifconfig

tun-ipv6              # queremos IPv6, don’t we?

comp-lzo          # compression

cd /etc/openvpn         # directorio donde tendremos el key generado.

secret static.key        # el archive con el key

persist-key         # si paso algo con el tunel, mantener el key

persist-tun         # si pasa algo con el tunel, mantener la interface

status /var/log/home.openvpn.status.log # LOGs

log-append /var/log/home.openvpn.log   # mas LOGs

keepalive 20 120

verb 5            # Verbose!

ifconfig 10.45.252.253 10.45.252.254

 

Todo esto lo tendremos en /etc/openvpn en un archivo llamado home.conf, OpenVPN detecta todos los archivos con .conf al final y los ejecuta para crear la interface y todo lo necesario para establecer el túnel.

En el Vyatta:

Aquí es algo diferente ya que los desarrolladores de Vyatta adaptaron OpenVPN a su CLI, si ya ha usado Vyatta, saben lo bien elaborado que esta el CLI.

edit interface openvpn vtun1 #creamos la interface vtun1, no podemos usar nuestros propios nombres aqui.

set local-address 10.45.252.254                #Nuestro lado del tunel

set local-host 10.0.0.2   #IP en la WAN con el DSL de CLARO

set local-port 1194          #no es necesario

set mode site-to-site    #tipo de tunel

set openvpn-options «–com-lzo –persist-tun –tun-ipv6»          #ya que algunas opciones no estan soportadas, existe la opcion de openvpn-options donde podemos usar las que faltan.

set protocol udp              #protocolo a ser usado por el tunel

set remote-address 10.45.252.253          #lado remoto del tunel

set remote-host 173.208.168.10              #IP WAN del servidor con Debian, nuestro Vyatta siempre iniciara la conexion ya que tiene IP Dinamico.

set remote-port 1194    #puerto donde realizaremos la conexión

set shared-secret-key-file          #archivo con el mismo key que usamos en el servidor.

commit

save

nota: no podemos usar comentarios en Vyatta, todo después del # no puede ser introducido en el CLI.

Al momento de hacer commit en Vyatta la configuración se aplica y este iniciara la conexión al servidor con OpenVPN, ahora debemos iniciar el OpenVPN en el servidor con Debian:

/etc/init.d/openvpn start home.conf

Automáticamente nuestro túnel debe subir y podemos hacer ping desde nuestro Vyatta hacia Debian usando la red 10.45.252.252/30.

Desde Vyatta: ping 10.45.252.253

Ahora solo nos faltaría que nuestro Vyatta y Debian sepan que redes maneja cada cual, esto en Vyatta lo podemos hacer así:

set protocol static route 172.22.114.0/26 next-hop 10.45.252.253

En nuestro servidor con Debian:

ip route add 172.22.35.0/26 via 10.45.252.254 dev tun-home

Ya nuestros equipos en ambos lados deben tener conectividad uno al otro usando el túnel.

Moviendo Debian de un servidor físico a Maquina Virtual

Hace varios días que tengo un nuevo host de VMware con ESXi 4.1 (información para un post..) y he decidido mover la mayoría de los equipos que tengo físicos a maquinas virtuales como ya lo había tenido en el pasado.

Buscando información de como usar VMware converter para convertir un Debian físico a VM, la información es algo escasa y muchas veces hacen referencia a correr el software en el entorno grafico el cual no tengo instalado en mi Debian. Por suerte existe rsync.

Los pasos fueron sencillos, primero cree una VM con Debian como Guest OS, luego de realizar una instalación mínima, instalo rsync en ambos equipos y estamos casi listos.

apt-get install rsync

/etc/init.d/cron stop; /etc/init.d/mysql stop

 

Si se esta corriendo otros servicios es recommendable detenerlos. En el servidor físico hacemos lo siguiente:

cd /

rsync –exclude dev/ –exclude proc/ –exclude sys/ –exclude etc/fstab \

–exclude boot/ –exclude etc/mtab –exclude etc/lvm/ -Rav –delete -e «ssh -c arcfour » \

./ root@maquina.virtual:/

 

Solo queda esperar que rsync termine, apagamos el servidor físico y reiniciamos la VM para terminar con nuestro sistema virtualizado!

Convirtiendo cualquier Linux en Debían, remotamente.

Hace varias semanas tengo disponible un equipo dedicado con muy buenas prestaciones el cual pretendía usar para virtualizar con VMware o como último recurso con XenServer, lamentablemente este equipo no tiene KVM y mucho menos forma de usar virtual media. Gracias a que el proveedor del dedicado tiene un modo “Recovery”, este funciona booteando el server via PXE con un LiveCD de Ubuntu, asi que con este modo podría intentar instalar ESXi.

Mi primer intento fue copiar el archivo imagendd al servidor para luego hacer un “dd if=imagedd of=/dev/sda” esto debería instalar ESXi, inmediatamente recordé que no tendría forma de introducir el password usando el DCUI asi que era una misión casi imposible. Luego pensé en instalar ESXi en un USB y bootear en un equipo con hardware similar al dedicado para asi crear una imagen desde ese USB ya con un password y las configuraciones que necesitaba. Al final me di cuenta que la controladora SATA no estaba en la HCL.

El segundo intento fue instalar XenServer en un equipo con procesador Opteron, el dedicado tiene un Opteron, lamentablemente otra vez el inconveniente al parecer era la controladora SATA, al parecer el Kernel en XenServer no tiene el modulo necesario para ver la controladora.

Ultimo intento fue Debianizar el servidor para instalar Proxmox. Esta ultima resulto y tengo el equipo funcional, no como deseaba pero por lo menos puedo virtualizar.

Si por alguna razón tienes un servidor remotamente inaccesible, y que no tenga Debian instalado y asi lo deseas, gracias a debootstrap esta tarea es más sencilla de lo que se pueda imaginar.

http://www.void.gr/kargig/blog/2009/04/02/howto-remotely-install-debian-over-gentoo-without-physical-access/

El “servidor”  en cuestión es un Fujitsu PRIMERGY MX130, lo bueno de este equipo es que es “green edition” y soporta hasta 16G de RAM. Lamentablemente al parecer para poder instalar ESX/ESXi en el, tendría que tener acceso a consola o por lo menos iKVM.

http://www.server4you.com/templates/images/downloads/ds-py-mx130s1_en.pdf