Planeta BSD

Ayer durante el curso -si, docente de nuevo- me plantearon una duda que hizo tambalear mis (repito, mis) cimientos de Software Libre (los cuales no están tan arraigados como debieran). Un usuario con -supongo- conocimientos en otros sistemas operativos propietarios se quedó dubitativo mientras intentaban comprender propietarios y permisos en *nix.

Despues de ver que un archivo tiene los permisos clasificados en su usuario propietario (u), grupo propietario (g) y otros (o) surgió la temida pregunta: ¿Y si tengo 3 ó 4 grupos y quiero dar distintos permisos a cada uno?. Pensadlo, porque chown, chmod y chgrp no solucionan esa papeleta (que yo sepa).

Leer el post completo »

En FreeBSD a veces pasa, después de un make update intentamos instalar un paquete del que creemos saber ubicación en el árbol de ports:

# cd /usr/ports/sysutils/portupgrade
/usr/ports/sysutils/portupgrade: No such file or directory.
#

¡¡Qué nooooo!! diría el bueno de Borat, ¡qué ya no está ahí!. Aunque si me fío del make search sigo en las mismas:

# cd /usr/ports/ ; make search name=portupgrade | grep Path
Path: /usr/ports/sysutils/portupgrade
#

¿Habrán cambiado su ubicación?… malas costumbres las de no actualizar el índice de la base de datos local, pero como de todo se aprende:

Leer el post completo »

Hablando de redes wireless toda medida de seguridad es poca para reducir el uso fraudulento de las mismas. En este caso con OpenBSD ejerciendo de punto de acceso los esfuerzos se minimizan.

He de decir que este tip no son más que un par de comandos sacados de una genial anotación del amigo Juanjo y de leer un par de páginas del manual (bridgename.if y brconfig). Ahora que ya sabeis dónde leer más y mejor, paso a pegar mi nota mental, para futuras ocasiones:

# cat /etc/bridgename.bridge0

add rl0
add ath0
up

# Wireless Client #1
rule pass in on ath0 src 00:aa:22:2a:1a:aa
rule pass out on ath0 src 00:aa:22:2a:1a:aa

# Wireless Client #2
rule pass in on ath0 src 11:bb:33:3b:2b:bb
rule pass out on ath0 src 11:bb:33:3b:2b:bb

# Blocked by default
rule block in on ath0
rule block out on ath0

Reiniciamos la configuración de la red (/etc/netstart ó brconfig bridge0 flushrule ath0) y con brconfig bridge0 ratificamos la corrección de las reglas. Probado y funcionando. Como diría años atrás… simplicity is divine!.

Leer el post completo »

http://www.nmsworld.com/FreeBSD61/Cacti.htm

Leer el post completo »

Al hilo de la anterior entrada y buscando alternativas para bloquear todos esos ataques por fuerza bruta (bruteforce) al servicio de administración remota SSH he encontrado la solución ideal -o lo que más se le aproxima-, sin descartar las anteriores.

La regla mágica hace uso de una nueva característica de Packet Filter (desde OpenBSD-3.7) llamada max-src-conn-rate. Lo que venimos a decirle a nuestro firewall es que permita todas las conexiones ssh con la salvedad de que no se sobrepasen 3 intentos en menos de 30 segundos, en dicho caso se agregará la IP del atacante a una lista llamada ssh-bruteforce, en pf.conf:

Leer el post completo »

Desde hace algún tiempo (Julio del 2003) el software de filtrado de paquetes más eficiente de todos los que conozco (olé la imparcialidad) ha sido portado a FreeBSD. Activarlo, dependiendo de la versión instalada, puede resultar no tan obvio como se desea.

Leer el post completo »

Echando un vistazo a los errores, warnings y demás variedad del BIND me he encontrado con más lame servers de los que esperaba:

03-Dec-2006 08:29:35.575 lame-servers: lame server resolving ‘ns1.globedns.biz’ (in ‘globedns.biz’?):211.155.129.3#53
03-Dec-2006 08:41:02.130 lame-servers: lame server resolving ‘antinegroismv.ws’ (in ‘ws’?): 202.4.48.217#53
03-Dec-2006 09:08:08.151 lame-servers: lame server resolving ‘vinilco.com’ (in ‘vinilco.com’?): 72.232.34.210#53
03-Dec-2006 09:31:33.644 lame-servers: lame server resolving ‘pian.so’ (in ’so’?): 205.166.226.38#53
…

Se supone (corríjanme si me equivoco) que estas máquinas no son quien dicen ser, tratando de engañar al ingenuo de nuestro servidor, ¿podría considerarse envenenamiento dns?, no sé hasta que punto pero por lo leido no afecta en el funcionamiento del servicio, con lo que podemos evitar su logueo y obtener informes más limpios. Dentro de la opción de logging en named.conf:

Leer el post completo »

Seguimos monitorizando una FreeBSD cualquiera, esta vez a través de analizadores gráficos de logs. Intentaremos instalar Cacti para recaudar la mayor información posible. Empezamos con la instalación propiamente dicha de Cacti (y todas sus dependencias: apache, expat, freetype2, mysql, net-snmp, perl, php4-mysql, php4-pcre, php4-session, php4-xml y rrdtool):

# portinstall -prfv /usr/ports/net/cacti

Presuponemos PHP y MySQL instalados de forma correcta, con lo que seguimos con la configuración de la tabla donde guardaremos todos los datos pertenecientes a la monitorización:

Leer el post completo »

Cuando los servidores se empeñan en imitar a las personas tratando de esconder sus más íntimos problemas, los BOFH intentamos hacer de psicólogos para medicarlos correctamente. Un buen test de estado podría ser el siguiente (siempre como root):

# top
# diskinfo -t /dev/adX
# systat -io 1
# systat -vmstat 1
# gstat
# iftop -i rl0
# ifstat -i rl0

El comando iftop ya lo habíamos visto en otra ocasión para visualizar de forma instantánea el tráfico de un interfaz concreto. Imagino que top lo conocemos todos, también para conocer el uso de memoria, procesador y procesos más activos.

Leer el post completo »

http://contenidosonline.blogspot.com/2006/07/raid-1-mirroring-con-freebsd-61_23.html

Leer el post completo »