Sobre la situación de Kaspersky con EEUU

Posted on by Josefina Arcidiacono

En estas últimas semanas, vienen saliendo distintas notas en diarios y blogs sobre el conflicto que hay entre EEUU y la empresa de seguridad rusa Kaspersky Lab.

Voy a hacer mi humilde esfuerzo por ordenar lo que vino pasando hasta ahora desde que empecé a seguir el tema.

Disclaimer: Esto es exclusivamente mi opinión personal y en base a las fuentes que yo encontré en internet.

Para los que vienen siguiendo el tema no voy a decir nada nuevo, y esto es solo una compilación y traducción de lo que vengo leyendo, sobre todo en Twitter y los portales de noticias.

13 de septiembre de 2017: Comunicado del Departamento de Seguridad de EEUU prohibiendo productos de Kaspersky en sus agencias.

(Link)

TL;DR: Por miedo a que las agencias de inteligencia rusa puedan exigirle a Kaspersky cooperar revelando información de las computadoras de sus usuarios, prohibieron el uso de sus productos en el Departamento de Seguridad. Básicamente por ser rusa.

El Departamento de Seguridad Nacional de los Estados Unidos (DHS) emitió un comunicado en el que ordenó a todas sus agencias y departamentos “identificar cualquier uso o presencia de productos de Kaspersky o sus sistemas de información (…) e implementar los planes para la discontinuación y remoción de los mismos de los sistemas de información”.

En el comunicado dicen basarse en “los riesgos de seguridad que conlleva usar productos de Kaspersky en los sistemas de información federales”, porque “los productos y soluciones de Kaspersky tienen amplio acceso a los archivos y privilegios elevados en las computadoras en las que están instalados”, lo cual podría ser explotado por actores maliciosos (léase otras agencias de inteligencia, hackers, terroristas, etc.).

El DHS dijo estar preocupado por posibles lazos entre ciertas personas en Kaspersky y la inteligencia rusa, y por “artículos en la ley rusa que permiten a las agencias de inteligencia pedir u ordenar cooperación de Kaspersky, e interceptar comunicaciones que pasan por redes rusas”.

Finalmente dice que “el gobierno ruso, por su cuenta o colaborando con Kaspersky, podría aprovecharse del acceso provisto por productos de Kaspersky para comprometer información federal, y es un riesgo que implica directamente a la seguridad nacional estadounidense”.

Hasta aquí el comunicado. Encontré una página que recopila y permite comparar legislaciones de inteligencia de diferentes países, recolectadas por abogados.

Por ejemplo, en la ley rusa
La ley aplicaría más que nada a los ISP y otras empresas de telecomunicaciones, y en principio no influiría en una empresa de antivirus como Kaspersky de manera directa.

Respuesta de Kaspersky Lab via @e_kaspersky (Eugene Kaspersky), el CEO y fundador de la empresa:

TL;DR: Kaspersky Lab dice que son acusaciones sin fundamento, que no tiene nada que ver con las agencias rusas y nadie presentó pruebas.

“Dado que Kaspersky Lab no tiene lazos inapropiados con ningún gobierno, la empresa está decepcionada con la decisión del Departamento de Seguridad Nacional de EEUU, y vamos a aprovechar esta oportunidad para brindarle a la agencia información adicional que confirma que estas acusaciones carecen completamente de fundamento. Ninguna persona ni organización presentó públicamente evidencia creíble ya que el alegato está basado en falsas acusaciones y suposiciones erróneas, incluyendo las afirmaciones acerca de la legislación rusa y las políticas que impactarían a la empresa”

Comunicado de prensa más extenso

Respecto del comunicado del DHS salió este artículo en PCMag UK sobre los rumores y la situación de Kaspersky, y tienen bastante más idea que yo.

No es la primera vez que EEUU hace este tipo de acusaciones a Kaspersky Lab, y su CEO ya ofreció mostrar el código de sus productos para disipar las sospechas.

Acá hay una nota de julio de este año al respecto en AP news.

Acusaciones en un artículo de opinión en el NY Times del 4 de septiembre

…y la respuesta en un comunicado de prensa de Kaspersky Lab.

 

14 de septiembre de 2017: El CEO de Kaspersky invitado a declarar frente a la Cámara de Representantes de Estados Unidos

TL;DR: El Congreso de EEUU llama al CEO de Kaspersky a declarar. E. Kaspersky acepta (si le dan una visa para entrar…). Después le posponen la audiencia. Continuará…

(Link)

 El comité de Ciencia, Espacio y Tecnología de la Cámara de Representantes de EEUU invitó oficialmente al CEO de Kaspersky Lab a declarar en una audiencia a realizarse el 27 de septiembre, “a la luz de sus repetidas ofertas de ‘reunirse con funcionarios del gobierno y testificar frente al congreso’”, para revisar “hasta qué punto el gobierno federal hace uso de los productos de su empresa”.

Respuesta de @e_kaspersky en Twitter:

“Acepté la invitación a testificar frente a la Cámara de Representantes de EEUU y responder las acusaciones sobre KL [Kaspersky Lab]. Ojalá que me den la visa.”

Challenge accepted!

Comunicado de prensa

Pero parece que reprogramaron la audiencia…

 

Mientras tanto, otras empresas de seguridad…

Aprovechando la situación, algunas empresas de seguridad como McAfee intentaron atraer a los clientes de Kaspersky en EEUU vendiendo “seguridad hecha en Estados Unidos”, apoyándose en que “el FBI aconseja no usar Kaspersky por sus supuestos lazos con espías rusos”

(via @e_kaspersky)

Al final de este artículo hay una recopilación de publicidades parecidas

5 de octubre de 2017: El Wall Street Journal publica un artículo acusando a Kaspersky de facilitar a los hackers rusos el robo de datos a la NSA en 2015

(Link)

Muy buen análisis y citas del artículo
En un artículo de The Wall Street Journal (WSJ), según informaron (anónimamente) “varias personas entendidas en el asunto”, hackers trabajando para el gobierno ruso robaron información altamente confidencial de la NSA en 2015. Un individuo contratado por de la NSA, según dijeron estas personas, se llevó esta información a la computadora de su casa, y estos hackers “habrían atacado la computadora después de haber identificado los archivos porque el empleado usaba un popular antivirus hecho por Kaspersky”. Expertos citados por WSJ dijeron que el software pudo haber detectado muestras de código malicioso en esa información, y lo que no se sabe es si “los técnicos de Kaspersky programaron el software para buscar (…) indicios de material de la NSA” o “si Kaspersky alertó al gobierno ruso del hallazgo”.

Nuevamente según “personas [anónimas] entendidas en el asunto”, “los investigadores sí determinaron que, valiéndose del conocimiento provisto por el software de Kaspersky (…), hackers contratados por Rusia localizaron la computadora y robaron gran cantidad de información”.

Además, el artículo menciona que la NSA no hizo declaraciones al respecto, y “el Departamento de Defensa, del cual la NSA es parte, tiene contrato con otra empresa antivirus, no Kaspersky”.

El artículo no cita una fuente concreta ni presenta pruebas acerca del empleado, su computadora o la participación de Kaspersky o los hackers.

Además, como bien dice el artículo de ArsTechnica, deja la duda de cómo consiguieron la información estos hackers: ¿Es un bug en el antivirus?, ¿Están comprometidas las redes y los sistemas de Kaspersky?, ¿Es a propósito, y Kaspersky les pasó la información directamente?

En cualquier caso, ¿qué hacía un empleado de la NSA llevándose información altamente confidencial a su casa? Haya tenido o no que ver Kaspersky en la filtración desde la computadora del empleado, hay una filtración desde la NSA a esa computadora antes por parte del empleado. Y si la NSA trabaja con malware para hacer espionaje, es de esperar que el antivirus lo detecte…

La respuesta de Kaspersky Lab al respecto en Twitter (via @e_kaspersky):

Comunicado de prensa

“Kaspersky Lab no recibió ninguna evidencia sustentando la participación de la empresa en el incidente del que se la acusa en el Wall Street Journal el 5 de octubre de 2017, y es desafortunado que la cobertura mediática de afirmaciones sin fundamento continúe perpetuando las acusaciones a la empresa.

“Reiteramos nuestra voluntad de trabajar junto con las autoridades de EEUU para responder a cualquier inquietud que puedan tener acerca de nuestros productos, y respetuosamente solicitamos cualquier información relevante que pueda permitir a la empresa comenzar una investigación lo antes posible

“Como la empresa privada que es, Kaspersky Lab no tiene lazos inapropiados con ningún gobierno, incluyendo Rusia, y la única conclusión es que Kaspersky quedó en medio de una contienda geopolítica.

“No vamos a disculparnos por ser agresivos en la batalla contra el malware y los cibercriminales. La empresa detecta activamente y mitiga infecciones de malware, sin importar su origen, y lo hemos estado haciendo orgullosamente durante 20 años, lo cual nos llevó a mantenernos en los primeros lugares en pruebas independientes de detección de malware. También es importante notar que los productos de Kaspersky Lab adhieren a los estrictos estándares de la industria de la ciberseguridad y tienen niveles de acceso y privilegios sobre los sistemas que protegen similares a los de otros populares proveedores de seguridad en EEUU y en todo el mundo”– Kaspersky Lab

Ya veremos cómo se sigue desarrollando esto en los próximos días.

 

 

BalckArch vs ArchStrike

Posted on by Epzylon

Como dije en el post de Hacking sobre debian:

mi laptop no solo es una herramienta de pentesting, si no tambíen mi herramienta de estudio, mi centro multimedia, me enviroment de programación, y mi herramienta de trabajo diario ademas de mi laboratorio de experimentos.

Es decir, la distro que utilice en mi pc tiene que tener capacidad y herramientas de todo tipo, no solo de seguridad informática.

Anteriormente, adecue Debian para que cumpla, dentro de lo posible, tales fines, sin embargo, justamente en materia de Seguridad informática, eran pocas las herramientas disponibles y poco actualizadas.
Al pasarme a ArchLinux, me tope con BlackArch y ArchStrike, dos distribuciones enfocadas a la seguridad informática, compatibles con su distribución madre, Arch.

Como y cual elegir?
Repasaremos un poco sobre ArchLinux, y luego sobre las versiones live de ArchStrike y BlackArch, veremos como utilizar ambos repositorios desde una instalacion de Arch y compararemos las herramientas disponibles.

Un poco sobre ArchLinux

Como dice en su pagina, Arch es  “a lightweight and flexible Linux distribution that tries to Keep It Simple”

Una de las mayores ventajas de esta distribución, es su comunidad activa, con documentación actualizada, al igual que sus repositorios, una cantidad inmensa de software disponible,  y una flexibilidad muy grande en cuanto a la configuración.
Esta misma flexibilidad, contrae la necesidad saber bien como configurar, administrar y actualizar cada parte del sistema operativo, sin destruirlo.
Por decirlo de otra manera, con Arch, vuelve la diversión de usar linux.

Una característica muy interesante, es que se trata de una distribución Rolling Release, es decir que el sistema de desarrollo de la distribución consiste en liberar continuamente actualizaciones, sin pasar por un estadio previo de pruebas/congelamiento. Por lo que al instalar Arch, tenemos siempre la ultima versión de cada paquete.

Entre las contras que tiene Arch (Por decirlo de alguna manera, ya que en realidad no es una contra si no, una característica adrede), es que Arch no tiene un instalador. Esto que puede asustar a los principiantes, es una ventaja para el usuario avanzado, evitándole caer en la obligación de aceptar configuraciones preestablecidas en un instalador.

Sobre ArchStrike y BlackArch (live)

Ambas distribuciones vienen en versiones live, lo que nos permite bajar sus respectivas ISOs y probarlas. En el caso de ArchStrike, podemos bajar un OVA, tanto para VirtualBox como para VMware, por lo que nos facilita probarla en una maquina virtual.

Menu

En el caso de BlackArch tiene un menu personalizado desde donde se puede acceder a todas las herramientas instaladas. Al igual que en Kali (una de las distros mas difundidas en materia de Pentesting) si la aplicacion/herramienta es de consola (como lo son la mayoria de las herramientas disponibles) abre una consola (xterm) ejecutando el comando sin argumentos.
A diferencia en ArchStrike, el menu no contiene un acceso a todas las aplicaciones, si no solo a las aplicaciones de interfaz graficas (algunas de linea de comando, pero no abre una terminal, por lo que no sirve para nada). Por otro lado, ArchStrike tiene otras herramientas orientadas a la configuracion del sistema y el escritorio que BlackArch no tiene (mas alla de la configuracion basica de fluxbox)

Estetica

Ambas vienen con Windows Managers livianos, en el caso de ArchStrike, OpenBox y Fluxbox por defecto para BlackArch, pero en esta ultima puede elegirse otros WMs, todos ellos livianos y con exactamente la misma estetica.blackarchlogin Esta seleccion de administradores de ventanas, ayuda a concentrarnos en el pentesting y no en otra cosa. Sin embargo, ArchStrike esta mas orientada a proveer una experiencia mas amigable. Por ejemplo, viene por defecto con wicd (un administrador de redes), un applet para mostrar la bateria (en caso de las laptops) y un menu que facilita el acceso a las herramientas de configuracion del sistema, como dije anteriormente.

Instalacion (live)

Ambas vienen con un script para instalar desde la version live, sin embargo solo ArchStrike tiene un acceso directo desde el menu principal. En el caso de BlackArch, hay que iniciarlo desde una terminal con el comando blackarch-install
archstrike

Repositorios

Mas alla del uso que podemos hacer de cada listro desde sus versiones live, podemos utillizar los repositorios de ambas distribuciones, como repositorios de una PC on Arch ya instalado.

BlackArch porvee un script que instala el repositorio y la base de datos de firmas correspondientes. Con estos pasos, quedan a disposicion nuestra las herramientas para ser instaladas:

curl -O https://blackarch.org/strap.sh
sha1sum strap.sh   #El resultado deberia ser  86eb4efb68918dbfdd1e22862a48fda20a8145ff
./strap.sh #Como root o con sudo

Luego de esto, podemos listar los paquetes disponibles de la siguiente manera:

pacman -Sgg | grep blackarch | cut -d' ' -f2 | sort -u

Estas instrucciones pueden leerlas en ingles en el siguiente guia en PDF

En el caso de ArchStrike, tenemos que adicionar un repositorio en el archivo de configuracion de Arch:

cat << EOF >> /etc/pacman.conf
[archstrike]
Server = https://mirror.archstrike.org/$arch/$repo
EOF

Seguido, actualizamos la base de datos de paquetes:

pacman -Syy

Para instalar la base de firmas, debes seguir los pasos indicados en la pagina oficial.

Coexistencia de repositorios: En este momento tengo configurados ambos repositorios y no he tenido problemas.

Herramientas disponibles

Un dato importante a la hora de comparar estas distribuciones es los paquetes disponibles, por lo que me tome el trabajo de hacer un recuento de los paquetes y sus respectivas versiones, transcribo a continuacion los pasos que seguí, por si les interesa repetirlos:
Primero hice una comparacion cuantitativa de los repositorios:

pacman -Sl | awk '/blackarch/ { print $2,$3 }' > /tmp/blackarch
pacman -Sl | awk '/archstrike/ { print $2,$3 }' > /tmp/archstrike
wc -l /tmp/blackarch /tmp/archstrike 
 2145 /tmp/blackarch
 1288 /tmp/archstrike

Como vemos, BalckArch tiene mayor cantidad de paquetes, sin embargo, esto no me dice mucho, ya que no se si los paquetes que tiene disponibles, son utiles, o desactualizados, o no me interesan.
Por lo que genere un archivo que compare ambos repositorios paquete por paquete, con su respectiva version:

cat /tmp/blackarch | sort > /tmp/blackarch.sorted
cat /tmp/archstrike | sort > /tmp/archstrike.sorted
cat /tmp/blackarch.sorted /tmp/archstrike.sorted  | awk '{ print $1 }' | sort -u > /tmp/allpkgs
join -a 1   archstrike.sorted blackarch.sorted
join -a 1 allpkgs archstrike.sorted > allvsstrike
join -a 1 allpkgs blackarch.sorted > allvsblack
join  -a 1 allvsblack allvsstrike  > black-strike.compared
cat black-strike.compared | tr ' ' ';'  > black-strike.compared.csv

De esta manera obtuve un CSV con todos los paquetes y sus respectivas versiones.
Les dejo a dispocision el CSV (black-strike-compared) y una planilla de calculo (black-strike-compared) que generé a partir del mismo.

Se puede ver con estos resultados, que BlackArch, tiene mas paquetes y en general estan mas actualizados. De hecho no hay paquetes que ArchStrike tenga y BlackArch no.

Conclusiones
Ambas distribuciones tienen su puntos fuertes, sin embargo, me pesa bastante la cantidad superior de paquetes que posee BlackArch, dado que si vamos a utilizar una de esta distribuciones, la estetica será algo que configuraremos por nosotros mismo, al igual que los menus. Por otro lado, BlackArch viene, en su version live, con varios Windows Managers interesantes, como Awesome, Fluxbox e i3, lo que le da un toque mas geek.
A su vez, ArchStrike es quizas una distro que puede abrirse camino en los menos experimentados, ya que provee una experiencia mas amigable.
En particular uso ambos repositorios en una instalacion de Arch ya existente, pero en linea general eh instalado los paquetes desde los repositorios de BlackArch.

Quizas haya algun dato que se me este pasando por alto, pero hasta donde yo puedo ver, mi recomendacion se inclina por BlackArch.

Espero les haya servido la comparación y espero sus comentarios!

~have fun

 

Podcasts de Seguridad!

Posted on by Epzylon

Les comparto una selección de podcast activos y muy buenos que he estado escuchando últimamente:

SANS Internet Storm Center Daily Network Security Podcast_logo
Este podcast es breve y sale sin falta todos los dias, ideal para actualizarte durante la mañana

Brakeing Down Security podcast
Este podcast tiene muy buen nivel de los temas tratados, es un poco mas largo, una hora al menos y sale regularmente todas las semanas

Paul’s Security Weekly
Este podcast esta estrenando una emisión semanal dedicado a la seguridad en las empresas, mientras continua con su acostumbrada y famosa periodicidad.

Down the Security Rabbithole
De periodicidad menos frecuente, pero constante, trata temas no tan técnicos en si pero muy interesantes a todo lo referente con la seguridad informática.

Defensive Security Podcast
Otro excelente podcast con temas relacionados con la seguridad informatica, de duración larga pero interesante.

Crimen Digital
Este podcast se especializa sobre todo en la parte forense de la seguridad informática. Lo mejor que escuche en español

Otros dos mas, sobre los que no tengo mucho para decir:
Security Advisor Alliance Podcast
Data Driven Security

RedHat Certified System Administrator 7 (RHCSA 7) – Sistemas en Funcionamiento III – LOGS

Posted on by Epzylon

Siguiendo con la serie de posts relacionados al RHCSA 7, hoy nos ocuparemos del objetivo que reza:

Ubicar e interpretar archivos de registro del sistema y diarios

Como lo venimos haciendo en posts anteriores (RHCSA, RHCSA I, y RHCSA II) haremos un somero repaso sobre los temas mas conocidos para un administrador linux y nos centraremos mas sobre las nuevas características de Red Hat 7.

En esta sencilla oración, “Ubicar e interpretar archivos de registro del sistema y diarios”, o mas estéticamente en ingles: “Locate and interpret system log files and journals.”
se nos pide tener un conocimiento, al menos básico de los logs y journals, así que… empecemos!

Logs, historicamente

Syslogd es un daemon originalmente creado por el autor de Sendmail, para ser usado solo por Sendmail, sin embargo, dado su utilidad, se convirtió en un estándar de facto[1] en los sistemas Unix, no solo para Sendmail, si no para administrar todos los registros.
Este estándar de facto consta de 2 partes principales, el daemon syslog y el protocolo syslog.
El daemon es el encargado de recibir (tanto desde el sistema local, como de otoso sistemas, remotamente) y escribir los registros de cada daemon y del mismo kernel. Por otro lado el protocolo es el que se encarga de transmitir mediante la red los registros, desde el daemon emisor al server syslog.

Como bien debes saber ( o no ), syslog establece una prioridad para cada mensaje, esta prioridad se compone por la identificación del recurso, y la severidad, a saber:

Recursos (facility)
0: Mensajes del kernel (kern)
1: Mensajes del nivel de usuario (user)
2: Sistema de correo (mail)
3: Demonios de sistema (daemon)
4: Seguridad/Autorización (auth)
5: Mensajes generados internamente por syslogd (syslog)
6: Subsistema de impresión (lpr)
7: Subsistema de noticias sobre la red (news)
8: Subsistema UUCP (uucp)
9: Demonio de reloj (clock)
10: Seguridad/Autorización (authpriv)
11: Demonio de FTP (ftp)
12: Subsistema de NTP
13: Inspección del registro
14: Alerta sobre el registro
15: Demonio de reloj (cron)
16: Uso local 0 (local0)
17: Uso local 1 (local1)
18: Uso local 2 (local2)
19: Uso local 3 (local3)
20: Uso local 4 (local4)
21: Uso local 5 (local5)
22: Uso local 6 (local6)
23: Uso local 7 (local7)

Severidades  (severity)
0: Emergencia: el sistema está inutilizable (emerg)
1: Alerta: se debe actuar inmediatamente (alert)
2: Crítico: condiciones críticas (crit)
3: Error: condiciones de error (err)
4: Peligro: condiciones de peligro (warning)
5: Aviso: normal, pero condiciones notables (notice)
6: Información: mensajes informativos (info)
7: Depuración: mensajes de bajo nivel (debug)

En base a la Prioridad (facility*8 + severity) el daemon syslogd determina donde guardara los registros.
Esta configuración la podíamos encontrar en /etc/syslog.conf y comúnmente apuntaba a algún archivo dentro del /var/log

Logs en Red Hat 7

Actualmente, y desde hace un tiempo Red Hat utiliza rsyslogd una implementación de syslog que implementa el RFC 3195 , TCP, SSL, carga de diferentes modulos y permite una gran variedad de funciones, que lo transforman en un excelente administrador de registros (logs).

Si bien la configuración de rsyslogd permite una enorme cantidad [2] de variables, su configuración por defecto refleja la utilización mas básica.

Si exploramos el /etc/rsyslog.conf veremos que las siguientes lineas nos indican donde buscar los distintos mensajes

#kern.*                                     /dev/console
*.info;mail.none;authpriv.none;cron.none    /var/log/messages
authpriv.*                                 /var/log/secure
mail.*                                    -/var/log/maillog
cron.*                                    /var/log/cron
uucp,news.crit                            /var/log/spooler
local7.*                                  /var/log/boot.log

Tenemos entonces aquí, un punto de partida para saber donde buscar registros,de los distintos daemons sobre los que trabajemos.
En este post hay un artículo sobre como configurar rsyslog para centralizar los registros.

Journald

Por otro lado, Red Hat 7 ya no necesita de un daemon que implemente syslog, para administrar los registros, ya que Journald, un daemon parte de la colección de novedades de systemd, administra y almacena los registros. En este documento, pueden encontrar las razones para utilizar una solución mas avanzada en la administración de logs.

Dentro de las características principales de journald, es que guarda los registros de forma indexada y en formato binario, esto nos permite, entre otras ventajas, poder buscar y visualizar los logs de forma mucho mas rápida y efectiva.

Journalctl

Para la tarea de visualizar los logs de journald, contamos con la herramienta journalctl. Ejecutándolo sin mas, obtendremos la salida de todos los logs almacenados con un ‘pager’, que nos permitirá navegar por los registros.
Con journalctl podemos filtrar por prioridad, por el programa que lo genero, por fecha, y por booteo sin necesidad de ‘entubar’ (usar tuberias/pipes) a otros programas.

Ejemplos:

#Obtener logs desde el ultimo booteo
journalctl -b
#Obtener lista de booteos
journalctl --list-boots
#Obtener logs de ssh
journalctl /sbin/sshd
#Obtener logs de una prioridad determinada
journalctl -p err
#Obtener los logs en base a fechas
journalctl --since=yesterday
journalctl --since=2016-04-01 --until=2016-04-12
#Salida analoga al tailf -f
journalctl -f

Todas estas opciones pueden complementarse entre si, para poder precisar de forma especifica lo que necesitamos, sin necesidad de andar escarbando entre archivos y concatenando greps y awks.
A mas de esto, journalctl nos permite especificar distintos formatos de salidas utilizando el parametro –output:

short
short-iso
short-precise
short-monotonic
verbose
export
json
json-pretty
json-sse
cat

Conclusion

Concluyendo, para tener un conocimiento básico de los logs en Red Hat 7, conviene utilizar journalctl para familiarizarnos con la herramienta, revisar un poco el man y buscar de lograr obtener toda la información que solíamos buscar antes de que systemd nos invadiera.

~have fun

[1] RFC 3164 es la definición original, actualmente no se encuentra en vigencia

[2] Manual de RedHat 7 sobre rsyslog

RedHat Certified System Administrator 7 (RHCSA 7) – Sistemas en Funcionamiento II

Posted on by Epzylon

Continuando con el post anterior (Redhat Certified System Administrator 7 Sistemas en Funcionamiento I) donde tratamos los primeros 3 puntos del segundo requerimiento del examen RHCSA.

A continuación continuaremos con el siguiente punto de forma sintética:

Identificar los procesos que hacen un uso intensivo de la CPU y de la memoria, ajustar la prioridad de los procesos con renice y eliminar procesos

Tradicionalmente, en cualquier unix ‘ps’ es el comando para identificar los procesos con sus respectivas características, cualidades y estados. Este tradicional comando, en los sistemas GNUs soporta 3 tipos de sintaxis para los parámetros, a saber: UNIX, BSD, y GNU. Para simplificar en este post utilizaremos la sintaxis UNIX la cual permite agrupar las distintas opciones y require un -.
Por ejemplo:

ps -aux

Cabe recalcar, ps a no es igual a ps -a.

Process Snapshot (ps)

El comando ps listará los procesos dependiendo de los parámetros modificadores que la pasemos.

Repasemos los mas pertinentes:
-e / -A  Listar todos los procesos
-x        Lista procesos que estén asociados a una terminal (TTY)-U       Lista los procesos asociados a un o varios usuarios
-o       Permite determinar que características del proceso se listaran

Los parámetros mas interesantes para -o son los siguientes:

%cpu        %CPU      cpu utilization of the process in "##.#" format. 
%mem        %MEM      ratio of the process's resident set size  to the physical memory on the machine, expressed as a percentage
args        COMMAND   command with all its arguments as a string. Modifications to the arguments may be shown.
cgroup      CGROUP    display control groups to which the process belongs.
ni          NI        nice value. This ranges from 19 (nicest) to -20 (not nice to others)
pid         PID       a number representing the process ID
ppid        PPID      parent process ID

Podemos entonces, combinar estos parámetros en una salida como la siguiente:

ps -e -o pid,%cpu,%mem,args

La cuál nos brindaría el pid, el porcentaje de CPU utilizado, el porcentaje de memoria utilizado y los argumentos con los cuales se ejecuto el programa. Otro parámetro interesante es cgroup, ya que desde que tenemos systemd, todos los procesos se ejecutan bajo el control de un grupo (control group).

Pueden encontrar estos parámetros y muchos mas haciendo ‘man ps’, en la sección STANDARD FORMAT SPECIFIERS

El último tip, es el siguiente: para poder ordenar la salida, utilizamos –sort, y especificamos en base a que parámetro queremos ordenar la salida.

Por ejemplo ordenaremos por porcentaje de procesamiento del CPU:

ps -e -o pid,%cpu,command --sort %cpu

Table of Process (top)

Otro comando clásico de los UNIXs, nos listara en tiempo real la table de procesos y su consumo de recursos. Así mismo, por defecto top ordena los procesos por su consumo de CPU, lo que nos facilita encontrar cuáles son los programas que mas recursos consumen.
Presionando r se podrá cambiar el número de prioridad de un proceso y con k podemos enviar una señal para matar al proceso.
Podrán encontrar un buen post sobre top aquí

Nice & renice

Los sistemas UNIXs permiten establecer prioridades de procesamiento para que el CPU se ‘concentre’ mayormente en ciertas tareas y relegue otras.
Nice permite ejecutar un comando con una prioridad determinada:

nice -n 5 comando --argumento

Si el proceso ya estuviese corriendo, podemos reasignarle la prioridad con renice referenciando su pid:

renice -n 4 2345

Kill y sus derivados

Finalmente, para eliminar un proceso, tenemos el comando kill.
Unix establece distintas señales que podemos enviarle a un proceso, las mas comunes son SIGHUP (1) (morir y volver a ejecutarse), SIGTERM (15) (le avisa al proceso que tiene que terminar su ejecución, pero le da tiempo de que cierre los file descriptors y mate a sus hijos) y SIGKILL (9) (termina el proceso inmediatamente)l.

Así, podemos enviarle estas señales utilizando el PID y el numero de señal:

kill -s 9 2345

Killall  y pkill nos permiten hacer lo mismo, pero buscando el proceso por nombre:

killall -s 9 xchat

Otro post interesante sobre el tema, aqui

Conclusión

Estos temas son básicos para cualquier administrador linux/unix, por lo que simplemente hicimos un brevisimo repaso, no hay diferencias en Red Hat 7 de lo que ya conocemos en este punto.

Saludos!

~have fun

RedHat Certified System Administrator 7 (RHCSA 7) – Sistemas en Funcionamiento I

Posted on by Epzylon

El segundo de los requerimientos incluidos en la certificación de Red Hat (versión 7) para System Administrator incluye los siguientes puntos:

Usar sistemas en funcionamiento
• Arrancar, reiniciar y apagar un sistema normalmente
• Iniciar sistemas manualmente en destinos diferentes
• Interrumpir el proceso de arranque con el fin de obtener acceso a un sistema
• Identificar los procesos que hacen un uso intensivo de la CPU y de la memoria,
ajustar la prioridad de los procesos con renice y eliminar procesos
• Ubicar e interpretar archivos de registro del sistema y diarios
• Acceder a la consola de una máquina virtual
• Iniciar y detener máquinas virtuales
• Transferir archivos entre diferentes sistemas de forma segura

Estos objetivos, aunque triviales para un administrador linux avezado, presentan un nuevo reto, ya que en esta versión del sistema del gorro rojo se ha incorporado systemd, agregando muchas mas funcionalidades y un poco de complejidad.

Desglosaremos brevemente los primeros 3 puntos en este post:

Arrancar, reiniciar y apagar un sistema normalmente

Puede que este enunciado nos tiente a pensar que ‘shutdown’, ‘reboot’ e ‘init’ sean los comandos necesarios para manejar el tema. Si bien es cierto, no lo es menos, que ahora todo el proceso de inicio, apagado y reinicio es administrado por systemd, por lo tanto, hemos de incorporar el systemd en nuestro repertorio de comandos:


# systemctl reboot

# systemctl halt

# systemctl poweroff

De todas formas podemos seguir utilizando los clásicos:

Reinicio

# reboot
# shutdown -r now
# init 6

Apagado

# halt
# shutdown -h now
# init 0

Apagado ACPI

# poweroff

Por otro lado, con systemd podemos administrar la suspensión/hibernación desde el mismo comando systemctl:

# systemctl suspend
# systemctl hibernate
# systemctl hybrid-sleep

Iniciar sistemas manualmente en destinos diferentes

Así mismo, con systemctl podremos administrar lo que antes conocíamos como ‘run levels’, ahora systemd introduce el concepto de ‘targets’ mejorando en gran manera las dependencias para pasar de un ‘target’ a otro.
Conocidos por todos, los run levels son:

  • 0, halt
  • 1, single: Single user o mantenimiento
  • 2: no network: sistema sin recursos de red
  • 3: multi usuario sin interfaz gráfica
  • 5: multi usuairio con interfaz gráfica
  • 6: reboot

Y podiamos pasar de uno a otro con el comando init:

#init 1

Y para saber en que run level nos encontramos podemos utilizar los siguientes comandos:

# runlevel
# who -r

systemd es compatible con todos estos comandos, pero se recomienda la utilización del comando systemctl, cuyo uso se detalla brevemente a continuación:

Single user con file systems locales montados:

#systemctl rescue

Single user sin file systems locales montados (sólo el /)

#systemctl emergency

Multi usuario sin interfaz gráfica

#systemctl isolate multi-user.target

Multi usuario con interfaz gráfica

#systemctl isolate graphical.target

También podemos, sin editar ningún archivo, configurar un target, como el target por defecto, utilizando:

#systemctl set-default multi-user.target

Y para saber cual es el run level por defecto

#systemctl get-default

 

Interrumpir el proceso de arranque con el fin de obtener acceso a un sistema

Este punto, aunque simple, es crucial en el examen, ya que difiere en absoluto de lo que solíamos hacer  (iniciar en single mode). En este link de Red Hat, se encuentra un procedimiento un poco mas detallado del que aquí expondremos y en este link, un método alternativo, un tanto mas a la vieja usanza.

Para interrumpir el proceso de arranque, acceder al sistema y cambiar el  pasword de root, seguiremos estos pasos:

  1.  Detenemos el conteo de grub y entramos en modo edición presionando la e
  2. Buscamos la linea que comienza con ‘linux’ (o ‘linux16 o ‘linuxefi’) y borramos los parametros ‘quiet’ y ‘rhgb’ para poder visualizar los mensajes del sistema.
  3. Agregamos el siguiente parametro: 
    rd.break enforcing=0

    Booteamos con ‘Ctrl-x’

  4. Nos encontraremos con el prompt de una shell del initramfs ‘switch_root’, desde donde montaremos el / con permiso de escritura: 
    switch_root:/# mount -o remount,rw /sysroot
  5. Utilizamos chroot para utilizar /sysroot como nuestro / 
    switch_root:/# chroot /sysroot
  6. Ya dentro de la shell del chroot, podemos ejecutar el comando passwd 
    sh-4.2# passwd
  7. Una vez cambiada la password, montamos el / como sólo lectura 
    sh-4.2# mount -o remount,ro /
  8. Salimos de la shell del chroot con exit y nuevamente con exit salimos de la shell del initramfs para continuar con el proceso de inicio
  9. Ejecutamos restorcon al archivo /etc/shadow para que contenga el contexto selinux adecuado 
    restorcon /etc/shadow
  10. Restablecemos selinux a enforcing mode: 
    #setenforce 1

Si necesitáramos iniciar en modo ‘rescue’ o ’emergency’, hemos de saber que es posible, editando la linea ‘linux’ (como hacemos en el paso 2) y agregando

systemd.unit=rescue.target

o

systemd.unit=emergency.target

En cualquiera de los dos casos, necesitaremos el password de root para acceder.

En el próximo post, seguiremos revisando los puntos importantes de este objetivo, hasta entonces:

~have fun

RedHat Certified System Administrator 7 (RHCSA 7) – Herramientas esenciales

Posted on by Epzylon

El primer punto de los requerimientos para certificar RedHat 7 como System Administrator, pide los siguientes requerimientos:

Conocer y usar las herramientas esenciales
• Acceder a una instancia shell y escribir comandos con sintaxis correcta
• Utilizar redirección de entrada-salida (>, >>, |, 2>, etc.)
• Utilizar expresiones regulares y grep para analizar texto
• Acceder a sistemas remotos mediante ssh
• Iniciar sesión y cambiar de usuario en destinos multiusuario
• Archivar, comprimir, desempaquetar y descomprimir archivos utilizando tar, star,
gzip y bzip2
• Crear y editar archivos de texto
• Crear, borrar, copiar y mover tanto archivos como directorios
• Crear enlaces físicos y simbólicos
• Enumerar, configurar y cambiar permisos ugo/rwx estándar
• Localizar, leer y utilizar documentación de sistema, incluido man, info y archivos
en /usr/share/doc

Como estos requerimientos suelen ser conocidos por cualquier administrador Unix/Linux, me limitaré a compartir con uds un Cheat Sheet, donde se ejemplifican en comandos los requerimientos.

 

~have fun

Net Tools vs IPRoute2 – Parte I

Posted on by Epzylon

 

Linux es una excelente plataforma para experimentar  y trabajar sobre networking. Las herramientas más básicas han sido heredadas de Unix (ifconfig,netstat,arp.. etc) y a decir verdad, estamos bastante cómodos con ellas. Sin embargo, hace años que el desarrollo de linux ha creado nuevas herramientas, mas poderosas aunque no tan populares; Como sabrán, me refiero, al set de herramientas iproute2.

La pregunta es: ¿Vale la pena el esfuerzo de cambiar a iproute2?

Veremos en los siguientes posts, ventajas y desventajas, uso y desusos…

Net Tools

Net Tools, también llamado mas precisamente NET-3 Networking toolkit, es un set de herramientas heredado históricamente de Unix.
Estas son: arp, hostname, ifconfig, netstat, rarp, route, plipconfig, slattach, mii-tool,  iptunnel  y ipmaddr.
A que algunas te han sorprendido eh!?
Hagamos un apropos:

arp (8): manipulate the system ARP cache
hostname (1): show or set the system's host name
ifconfig (8): configure a network interface
netstat (8):  Print network connections, routing tables, interface statistics, masquerade connections, and multicast memberships
rarp (8): manipulate the system RARP table
route (8): show / manipulate the IP routing table
plipconfig (8): fine tune PLIP device parameters
slattach (8): attach a network interface to a serial line
mii-tool (8): view, manipulate media-independent interface status
iptunnel (8): creates, deletes, and displays configured tunnels
ipmaddr (8): adds, deletes, and displays multicast addresses

Ahora bien, si utilizas linux dia a dia, muy difícilmente no conozcas arp, netstat, ifconfig, hostname y route, si no conoces algunos de esos comandos, este artículo no es para vos; Sin embargo, el resto de los comandos se utilizan en situaciones mas especificas.
Convenimos pues, en que la costumbre y la simplicidad histórica de estos comandos nos gustan.
Sin embargo, veamos ahora, como una comparación con IPRoute2 nos da una mejor idea de las diferencias que hay entre ambos.

IPRoute 2

El protagonista de iproute2 es el comando ip, en el cual se resumen la mayoría de las tareas que solíamos hacer con net-tools.
Aquí tenemos una pequeña tabla de referencia:

ifconfig ip addr show
arp ip neigh show
route -n ip route show

Hay mas, pero esto sirve para que veas que el comando ip se robará el protagonismo. Desde el comando ip podremos configurar prácticamente todo lo relacionado con las redes en linux.

Veamos como usar iproute en el día a día y dejaremos para mas adelante, las opciones mas avanzadas:

Rutas

Listar rutas:

Con net-tools usabamos:

route -n

Ahora con ip route podemos usar:
ip route | ip route ls | ip route show
Cualquiera de estos tres comandos nos da como resultado algo como lo siguiente:

default via 192.168.1.1 dev eth0 proto static
10.42.0.0/24 dev wlan0 proto kernel scope link src 10.42.0.1 metric 9
148.91.164.0/24 dev eth0 proto kernel scope link src 148.91.164.131 metric 1
169.254.0.0/16 dev eth0 scope link metric 1000

Mas adelante veremos como hacer un filtrado por tipo de ruta y otras caracteristicas, pero sigamos por lo básico.

Agregar una ruta:

Con net-tools usabamos:

route add -host ip ip-gw
route add -net netip-gw

Ahora utilizamos:

ip route add ip/net via ip-gw

Por ejemplo:

ip route add 10.1.1.0/24 via 192.168.4.1

o bien:

ip route add 10.1.1.20 via 192.168.4.1

Como verán, es indistinto si es un host o una red. Nos es muy diferente en principio, pero mas adelante veremos cuantas otras opciones tenemos para agregar.

Quitar una ruta:

Con net-tools usabamos:

route del -host ip gw ip_dw
route del -net net gw ip_gw

Ahora utilizamos:

ip route del ip via ip_gw
ip route del net via ip_gw

Direcciones IP

Es dificil pensar en no usar el ‘ifconfig’, pero hagamos un intento y veamos que sale:

Listar interfaces

Con net-tools usabamos
ifconfig | ifconfig -a

Con iproute utilizamos

ip addr | ip addr list | ip addr show

Que nos devolverá un output como el siguiente:

1: lo: &lt;LOOPBACK,UP,LOWER_UP&gt; mtu 16436 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 63:34:55:66:11:3a brd ff:ff:ff:ff:ff:ff
inet 123.41.14.135/24</strong> brd 123.41.14.255 scope global eth0
inet6 fe80::6531:50ff:fe68:1d34/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: &lt;BROADCAST,MULTICAST&gt; mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:26:82:dc:9d:51 brd ff:ff:ff:ff:ff:ff

En principio, el output de ip addr tiene mas info del que acostumbramos con ifconfig, pero nada de que preocuparse. Verán señalado en el output anterior, alguna data interesante señalada.

Asignar direcciones:

Con net-tools usabamos ifconfig de la siguiente manera para asignar una dirección IP:

ifconfig eth0 ip netmask netmask

Con iproute usaremos:

ip addr add ip/prefix dev eth0

Y para eleminar una ip de manera similar:

ip addr del ip/prefix dev eth0

Primeras conclusiones

Si bien iproute no parece incrementar la dificultad de configurar básicamente nuestras redes, no deja de ser cierto que la costumbre tira para seguir usando el viejo set de utilidades unix-like, sin embargo, en los próximos posts veremos usos mas avanzados y útiles que haran inclinar la balanza.

~have fun

Primeros pasos con NetBSD II

Posted on by Epzylon

En el primer post vimos algunos aspectos básicos de NetBSD, suficiente como para que los curiosos se adentren a explorar este OS. En este post veremos una configuración que nos permite utilizar NetBSD como router, esta configuración no escapa de ser básica, pero puede ser muy útil.

NetBSD como router

Uno de los usos mas básicos que podemos darle a un NetBSD es utilizarlo como router. Aunque quizás  en primera instancia pensaríamos en OpenBSD o Linux para dicha tarea, puede ser que tengamos guardada alguna PC muy vieja donde es mas dificil instalar OpenBSD y muy chica para Linux. En la lista de productos basados en NetBSD que mencionamos en el post anterior, podemos encontrar algunos routers desarrollados en base a este OS.
Otra razón para hacer esto es simplemente por que podemos, y nos gusta experimentar.

Escenario:

Tenemos una pc (o cualquier bicho que pueda correr NetBSD) con dos conexiones. netbsd-router
Una de las cuales tiene conexión a la Internet y la otra a la intranet a la cual proveeremos de acceso a internet. El nombre de la interfaz conectada a internet será wm0 y la interfaz conectada a la intranet será wm1.

Consideraremos en otro momento , un escenario donde la conexión a internet se realiza mediante una conexión DSL.

Configuración de las interfaces

IP Estatica

Como ya mencionamos en el post anterior, la configuración de las interfaces es muy simple.
Para poder saber las interfaces (los nombres de las interfaces dependen del driver utilizado en los kernels *BSD) disponibles utilizamos ifconfig:

ifconfig -a

Por cada interfaz disponible obtendremos un resultado similar al siguiente:

wm0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
 capabilities=2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx,UDP6CSUM_Tx>
 enabled=0
 address: 56:43:13:45:4d:af
 media: Ethernet autoselect (1000baseT full-duplex)
 status: active
wm1: flags=8843<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
 capabilities=2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx,UDP6CSUM_Tx>
 enabled=0
 address: 03:34:31:43:55:ff
 media: Ethernet autoselect (1000baseT full-duplex)
 status: active

Al igual que en GNU/Linux y demases unix podemos configurar temporalmente la interfaz utilizando:

ifconfig wm0 10.0.0.1 netmask 255.255.255.0
ifconfig wm1 192.168.1.1 netmask 255.255.255.0

Pero para poder configurar de forma definitiva la interfaz, debemos crear (si no existe ya) el archivo /etc/ifconfig.wm0 y el /etc/ifconfig.wm1. En este archivo, simplemente añadiremos en cada linea los argumentos que queremos que ifconfig ejecute. Por ejemplo, lo primero a hacer es levantar la interfaz con un:

ifconfig wm0 up

Por lo que la primer linea del archivo será un ‘up’.
Luego configuraremos la ip y el archivo quedará de la siguiente manera:

NetBSD Lab # cat /etc/ifconfig.wm1
up
192.168.1.1 netmask 255.255.255.0
NetBSD Lab # cat /etc/ifconfig.wm0
up
10.0.0.1 netmask 255.255.255.0

De esta manera configuramos ambas interfaces de forma estatica.

DHCP cliente

En caso de que la interfaz con acceso a internet deba ser configurada con DHCP, el archivo de configuración se verá de la siguiente forma:

NetBSD Lab # cat /etc/ifconfig.wm0
up
dhcp

Donde wm0 es la interfaz que utliza dhcp.
Para utilizar DHCP en la interfaz sin reiniciar utilizar /etc/rc.d/networking stop/start, podemos utilizar:

# dhclient wm0

Packet Forwarding

Para habilitar el reenvio de paquetes, fundamental para un router ejecutamos lo siguiente:

# sysctl -w net.inet.ip.forwarding=1

Y para guardar esta configuración de forma permanente agregamos la siguiente variable a /etc/sysctl.conf:

# net.inet.ip.forwarding=1

Pero el reenvio de paquetes es sólo el primer paso, ya que necesitamos hacer NAT para que los paquetes puedan regresar correctamente, esto lo hacemos modificando el archivo /etc/ipnat.conf.
Si no existe, lo creamos de la siguiente manera:

NetBSD Lab # cat << EOF > /etc/ipnat.conf 
map wm0 192.168.1.0/24 -> 0/32 
EOF

Servicios del Router

DNS y DHCP

Para proveer un servicio de dns y dhcp a la red interna, instalaremos dnsmasq

NetBSD Lab # pkg_add -v dnsmasq
pkg_add: Warning: package `dnsmasq-2.67nb1' was built for a platform:
pkg_add: NetBSD/x86_64 6.0 (pkg) vs. NetBSD/x86_64 6.1.5 (this host)
Running install with PRE-INSTALL for dnsmasq-2.67nb1.
dnsmasq-2.67nb1: Creating group ``dnsmasq''
dnsmasq-2.67nb1: Creating user ``dnsmasq''
useradd: Warning: home directory `/nonexistent' doesn't exist, and -m was not specified
man/man8/dnsmasq.8
sbin/dnsmasq
share/examples/dnsmasq/dnsmasq.conf.example
share/examples/rc.d/dnsmasq
Running install with PRE-INSTALL for dnsmasq-2.67nb1.
dnsmasq-2.67nb1: copying /usr/pkg/share/examples/dnsmasq/dnsmasq.conf.example to /usr/pkg/etc/dnsmasq.conf
===========================================================================
The following files should be created for dnsmasq-2.67nb1:

/etc/rc.d/dnsmasq (m=0755)
 [/usr/pkg/share/examples/rc.d/dnsmasq]

===========================================================================
Package dnsmasq-2.67nb1 registered in /var/db/pkg/dnsmasq-2.67nb1

Luego, copiamos el script de inicio y el de configuración:

NetBSD Lab # cp /usr/pkg/share/examples/rc.d/dnsmasq /etc/rc.d/
NetBSD Lab # cp /usr/pkg/share/examples/dnsmasq/dnsmasq.conf.example /etc/dnsmasq.conf

Para activar el inicio de dnsmasq en el booteo, agregamos la siguientes lineas al /etc/rc.conf:

dnsmaq=YES
dnsmasq_flags="-C /etc/dnsmasq.conf"

Una vez hecho esto, debemos modificar las siguientes variables dentro de /etc/dnsmasq.conf

interface=wm1
bind-interfaces
expand-hosts
domain=netsecure.com.ar
dhcp-range=192.168.1.2,192.168.1.20,24h

En la variable interface utilizaremos la interfaz sobre la cual daremos internet a la red interna.
Como pueden ver, con esta simple configuración, dnsmasq brinda servicio de dns (forwarding) y dhcp.
Y comenzamos a disfrutar de los servicios de dnsmasq iniciandoló:

NetBSD Lab #  /etc/rc.d/dnsmasq start
Starting dnsmasq.

Firewall

NetBSD trae por defecto a PF como su firewall, PF (Packet Filter), es un firewall mantenido por el equipo de desarrollo de OpenBSD, uno de los sistemas mas seguros (el mas seguro?). Por esto y mucho mas, PF se ha granjeado su fama como excelente firewall, ademas de ser muy simple en su sintaxis, algo que su competencia (iptables/netfilter) no puede superar.
Para habilitar el uso de PF, modificamos el /etc/rc.conf:

pf=YES

Y luego deberemos configurar el funcionamiento en sí de pf en el /etc/pf.conf
Si bien la configuración del firewall es algo bastante personal (intimo diría yo), un ejemplo de un firewall básico podría ser el siguiente (manual de PF aquí)

#Bloqueamos todo por defecto
block in  all
block out all

#Lista de puestos permitidos para la red interna
allowed_tcp_ports = "{ 22 }"
allowed_udp_ports = "{ 53, 67, 68 }"

#Reglas para permitir el acceso a los puertos desde la red interna
pass in  on wm1 from 192.168.1.0/24 to 192.168.1.1 tcp port $allowed_tcp_ports
pass in  on wm1 from 192.168.1.0/24 to 192.168.1.1 tcp port $allowed_udp_ports
pass out on wm1 from 192.168.1.1 to 192.168.1.0/24 tcp port $allowed_tcp_ports
pass out on wm1 from 192.168.1.1 to 192.168.1.0/24 tcp port $allowed_udp_ports

Herramientas Adicionales

Finalmente, podemos instalar algunas herramientas utilizando (pkg_add) que pueden servirnos para controlar nuestra red:

  • fping (scanner icmp)
  • bmon (Para visualizar el ancho de banda en cada interfaz)
  • trafshow (Para visualizar las conexiones en tiempo real)
  • tinc (Para crear VPNs)
  • tcpdump (sniffer)

Conclusiones

Con esta configuración básica como router, tenemos la base para transformar nuestro NetBSD en un firewall bastion, en un proxy, un punto de control, etc. Una de las mayores ventajas de utilizar NetBSD como router es que puede ser instalado en muchos dispositivos, por lo que quizas puedas utilizar este OS en un router, en una PC o vaya a saber en que aparatejo. La liviandad del OS lo transforma ideal para correr en hardware reducido, pero al mismo tiempo proveer muchas funcionalidades.