Userlinux http://www.userlinux.net/ wireless, seguridad, administración, blogs, redes Sat, 06 Sep 2008 12:19:56 +0000 es-ES r0sk@userlinux.net(Oscar M. Lage) http://www.userlinux.net/themes/lab2/images/feed.png Userlinux http://www.userlinux.net/ OpenBSD 4.4: reservas disponibles http://www.userlinux.net/noticia.1379.php http://www.userlinux.net/noticia.1379.php#comments http://www.userlinux.net/noticia.1379.php sistemas pre-order Hasta el 1 de noviembre -teóricamente- no saldrá la nueva versión 4.4 de nuestro sistema operativo favorito, sin embargo las reservas ya están disponibles.
OpenBSD 4.4 pre-order
Comentan en undeadly que la release de este año es especialmente simbólica al coincidir en versión con su padre 4.4BSD-Lite (de Junio del 94). Como siempre, con gratas - sorpresas en su interior.

pre-order

]]>
Sat, 06 Sep 2008 12:19:56 +0200
Compilando Gnome2 http://www.userlinux.net/noticia.1307.php http://www.userlinux.net/noticia.1307.php#comments http://www.userlinux.net/noticia.1307.php sistemas gnomefreebsd Cuaderno de bitácora, 22:46. Esto es una locura, el único equipo sobremesa que tengo por casa lleva desde las 14:30 -aproximadamente- compilando Gnome2 (en FreeBSD-7.0) y todavía no ha acabado.

Ni idea de lo que le queda pero teniendo en cuenta sus 256 Mb. de RAM y el gigahertzio con el que trabaja, es posible que se le haga la noche muuuy larga.

gnome freebsd

]]>
Fri, 18 Apr 2008 22:37:57 +0200
Uptime: New world record http://www.userlinux.net/noticia.1286.php http://www.userlinux.net/noticia.1286.php#comments http://www.userlinux.net/noticia.1286.php sistemas uptimebash Luego si me encuentro con ánimo explicaré el motivo, pero dejo de administrar este pedazo de uptime y me apetecía fardar de ello:
# uname
FreeBSD
# uptime
 7:52PM  up 442 days,  8:29, 4 users, load averages: 0.04, 0.06, 0.02
¡Qué todo vaya bien en sus nuevas manos!.

uptime bash

]]>
Fri, 29 Feb 2008 19:51:07 +0200
CVS: cvsweb con y sin chroot http://www.userlinux.net/noticia.1224.php http://www.userlinux.net/noticia.1224.php#comments http://www.userlinux.net/noticia.1224.php sistemas cvswebchrootopenbsd CVSweb es un cgi que podemos instalar en el httpd para acceder al código fuente de nuestros repositorios y módulos cvs navegando por ellos como si de una página web se tratara (ejemplo).

Al ser un .cgi lo lógico es que vaya en el directorio cgi-bin/ del servidor, pero esto puede presentar más de un problema, bien porque no funcionen enlaces internos, hojas de estilo... y nos obligue a colocar ciertos archivos en ubicaciones predeterminadas que no gustan demasiado, bien porque queramos poner restricciones de acceso a través de .htaccess y presente un inconveniente dentro de cgi-bin.

Instalación

Por ello intentaremos instalar cvsweb fuera de su ubicación determinada y con unas condiciones especiales. Descomprimimos la descarga en donde la queramos instalar. Antes de continuar damos permisos de ejecución al cgi dentro del directorio destino, por ejemplo /var/www/dev.midominio.com/. Hecho esto modificamos el VirtualHost del dominio para que permita ejecutar cgi-scripts:
<VirtualHost *:80>
	...
	<Directory /var/www/dev.midominio.com/ >
		Options +ExecCGI
		AddHandler cgi-script cgi pl
	</Directory>
</VirtualHost>
Ahora colocamos cvsweb.cgi -con los convenientes permisos de ejecución si no queremos obtener un Error 500 ;)- y cvsweb.conf en ese directorio comprobando que ambos se ven (en versiones antiguas con estos 2 ficheros bastaba, ahora es posible que también haya -al menos- un directorio css/):
# grep cvsweb.conf cvsweb.cgi | head -1
 for ("$mydir/cvsweb.conf", 'cvsweb.conf') {
Ajustando la ruta si fuera necesario (en este caso están en la misma ubicación). Editamos también cvsweb.conf para configurar la ruta en la que está el repositorio (/cvs/public en este entorno):
# grep Repository cvsweb.conf | more
        'public' => ['Public Repository', '/cvs/public'],
En el siguiente reinicio del servidor web ya estaría todo funcionando.

Con contraseña

Ahora queremos proteger nuestro repositorio con una contraseña para que nadie espíe el código fuente :P, nos servimos del típico .htaccess:
AuthName "Zona Restringida"
AuthType Basic
AuthUserFile conf/users

require user miusuario
Y creamos el archivo conf/users con htpasswd:
# htpasswd -c conf/users miusurio      
New password: 
Re-type new password: 
#

Dos repositorios

Para rizar el rizo ahora quiero dos repositorios, uno con código fuente visible para todo el mundo y otro solo para desarrolladores de ciertos módulos, con lo que, dentro del mismo Virtualhost creo dos carpetas distintas public/ y private/.

Las directivas anteriores (Options +ExecCGI y AddHandler cgi-script cgi pl) están aplicadas a todo el dominio (subdominio en este caso) así que no tendré problema. Dentro de esas carpetas ubicamos los cvsweb y el .htaccess donde corresponda:
# ls -las private/
  4 drwxr-xr-x  2 root  r0sk      512 Nov 14 18:22 .
  4 drwxr-xr-x  4 root  r0sk      512 Nov 12 20:37 ..
  4 -rw-r--r--  1 www   www        88 Nov 12 19:00 .htaccess
192 -r-xr-xr-x  1 root  r0sk    96278 Nov 12 20:06 cvsweb.cgi
 32 -rw-r--r--  1 root  daemon  15557 Nov 12 20:07 cvsweb.conf

# ls -las public/
  4 drwxr-xr-x  2 root  r0sk      512 Nov 12 20:06 .
  4 drwxr-xr-x  4 root  r0sk      512 Nov 12 20:37 ..
192 -r-xr-xr-x  1 root  r0sk    96278 Nov 12 20:06 cvsweb.cgi
 32 -rw-r--r--  1 root  daemon  15557 Nov 12 20:06 cvsweb.conf
Private está protegido por contraseña (como hemos visto en el apartado anterior) mientras que Public está abierto a todo el mundo. Ojo, estoy utilizando dos repositorios cvs distintos:
# cat private/cvsweb.conf | grep Repository
'private' => ['Private Repository', '/cvs/private'],

# cat public/cvsweb.conf | grep Repository
        'public'  => ['Public Repository', '/cvs/public'],

Chrooted httpd

Si tu servidor web está enjaulado -chrooted- (como por ejemplo el httpd de OpenBSD) tendrás un poco más de trabajo copiando las librerías necesarias dentro del chroot para que todo funcione. A mayores todas las rutas de configuración serán absolutas al chroot (siendo /var/www la jaula, /var/www/conf pasa a ser /conf, etc). Instrucciones de enjaulado:
$ cd /var/www
# mkdir {tmp,usr}
# chown www:www tmp

$ cd /var/www/usr
# mkdir -p {bin,lib,libdata/perl5,libexec}

$ cd /var/www/usr/libdata/perl5
# mkdir -p {File,IPC,Time,warnings,`machine`-openbsd/5.8.6}

$ cd /var/www/usr/bin
# cp -p /usr/bin/{co,cvs,diff,perl,rcsdiff,rlog,uname} .

$ cd /var/www/usr/lib
# cp -p /usr/lib/lib{c,crypto,des,gssapi,krb5,m,perl,util,z}.so* .

$ cd /var/www/usr/libexec
# cp -p /usr/libexec/ld.so .

$ cd /var/www/usr/libdata/perl5
# cp -p /usr/libdata/perl5/{Carp,Exporter,Symbol,base,integer}.pm .
# cp -p /usr/libdata/perl5/{strict,warnings,vars}.pm .
# cp -p /usr/libdata/perl5/File/Basename.pm ./File/
# cp -p /usr/libdata/perl5/IPC/Open{2,3}.pm ./IPC/
# cp -p /usr/libdata/perl5/Time/Local.pm ./Time/
# cp -p /usr/libdata/perl5/warnings/register.pm ./warnings/

$ cd /var/www/usr/libdata/perl5/`machine`-openbsd/5.8.6
# cp -p /usr/libdata/perl5/`machine`-openbsd/5.8.6/{Config,Cwd}.pm .
Cuidado en los ficheros de configuración:
/var/www/cgi-bin/cvsweb:
  for ("$mydir/cvsweb.conf", '/var/www/conf/cvsweb/cvsweb.conf') {   (default)
  for ("$mydir/cvsweb.conf", '/conf/cvsweb/cvsweb.conf') {           (chroot)
/var/www/conf/cvsweb/cvsweb.conf:
  @CVSrepositories = (
    'local'   => ['Local Repository', '/home/cvs'],   (default)
    'local'   => ['Local Repository', '/cvs'],        (chroot)

    $mime_types = '/var/www/conf/mime.types';         (default)
    $mime_types = '/conf/mime.types';                 (chroot)

Screenshot

CVSweb
cvsweb en acción

cvsweb chroot openbsd

]]>
Wed, 14 Nov 2007 18:45:48 +0200
Jugando con mailq http://www.userlinux.net/noticia.1211.php http://www.userlinux.net/noticia.1211.php#comments http://www.userlinux.net/noticia.1211.php sistemas freebsdpostfixmailqpostsupermta Cuando falla la entrega en un servidor de correo lo lógico es que la cola se vaya llenando hasta reparar el problema. En ese momento las peticiones irán saliendo con cierto orden de prioridad. Hay varios comandos con los que podemos jugar para ayudar al servidor en el proceso de peticiones.

Con un poco de paciencia, conocimientos mínimos de bash y usando tanto mailq como postsuper (Postfix) podremos facilitar el flujo de correos encolados. Vamos a ello.

Primero miramos el número de correos que tenemos en cola. Esta operación se puede hacer de diversos modos:
# mailq | tail -n1
-- 70865 Kbytes in 1654 Requests.
# mailq | grep Requests
-- 70865 Kbytes in 1654 Requests.
Una vez sabemos el número exacto de correos que están esperando a ser procesados podemos hacernos una idea del tiempo que nos puede llevar reestablecer el normal funcionamiento del servicio.

Para ver una descripción algo más detallada de los correos (id, fecha, origen, destino...) podemos usar mailq sin más modificadores, obviamente el resultado será un chorizo tremendo si hay muchos Requests. Probemos a ver las 20 primeras lineas:
# mailq | head -n20
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
9A792414C6B*   30256 Fri Oct 26 11:41:30  tequilasunrise270@liberotta.it
                                         alguien@server

387924150E9*   41997 Fri Oct 26 11:26:53  1784@lavoca.es
                                         mas@server

1AB8D4141C3*    1163 Fri Oct 26 11:29:51  AIMEE-Jenksya@ariastone.com
                                         otrouser@server

D5808414C6F*   22998 Fri Oct 26 11:41:35  sateve@zongati.com
                                         alguien@server

81983414DDC*     518 Fri Oct 26 11:28:13  otrouser@server
                                         alguien@server

274104137A6*  170349 Fri Oct 26 11:28:19  tequilasunrise270@liberotta.it
                                         mas@server

CCC684141CC*   38295 Fri Oct 26 11:29:20  sateve@zongati.com
Nota: He modificado las direcciones de correo por no facilitar datos reales que puedan afectar al ejemplo ni al correcto funcionamiento de dichas cuentas.

Podemos comprobar que algunos de los correos en cola son correctos, otros spam o correo no deseado. Como trataremos de facilitar la tarea del servidor, podemos borrar los que veamos como no deseados.

Pongamos que tequilasunrise270@liberotta.it es uno de los correos a eliminar, nos fijamos en su ID (primer campo): 9A792414C6B y lo referenciamos con postsuper -d:
# postsuper -d 9A792414C6B
postsuper: 9A792414C6B: removed
postsuper: Deleted: 1 message
#
Sencillo -aunque tedioso- si la cola no llega a 50 correos, si jugamos con números más grandes el asunto se complica y el proceso empieza a alargarse notablemente en el tiempo. Es la hora de aplicar un poco de scripting.

Imaginemos que tequilasunrise270@liberotta.it nos ha estado inundando a correos en casi todas las cuentas del servidor, en vez de ir buscando el ID de una en una:
# mailq | grep tequilasunrise270@liberotta.it
Podemos sacar de forma más directa el ID con cut y pasarlo como parámetro a postsuper para que el trabajo sea más rápido (el ejemplo se ejecuta con una cuenta de correo, pero podríamos filtrar todo un dominio de la misma forma):
# for i in `mailq | grep tequilasunrise270@liberotta.it | cut -f1 -d*`; do postsuper -d $i; done
postsuper: 769024147F2: removed
postsuper: Deleted: 1 message
postsuper: 93A4B415197: removed
postsuper: Deleted: 1 message
postsuper: BD9FC414BFB: removed
postsuper: Deleted: 1 message
postsuper: 024EF4150C2: removed
postsuper: Deleted: 1 message
postsuper: 12114414813: removed
postsuper: Deleted: 1 message
...
#
Otra opción que se me ocurre así a bote pronto es generar a partir de mailq una lista negra de direcciones spam y borrar todos los correos estén en cola y hagan referencia a ellas.

Empezamos creando un archivo con la lista de todas las direcciones de correos implicados en cola, por ejemplo:
# mailq | grep : | cut -f3 -d":" | cut -f3 -d" " | sort  > ~/mailq.log
# cat ~/mailq.log
14479TDJAR@rrew.com
1919@intl-error.mail.info
3F2ZB9R@barriage.com
4QC5TBFN4Y@rarnyne.net
5minnews.com@kingofthedirt.com
71V8V5@rarrgoico.net
7AP31N@rarrlolico.com
96ZEXFSXB@rarrisolidp.com
9DTOUY@rarrgoldmine.com
aalguien@server.com
Aprafivo69@abebooks.com
BenaeMilne@meiselania.cc
Boospq@123456.com
bueno@server.com
Casey.Wood@jermanyfromhome.net
DAVEY879@RUBIAZA.DE
dario@server.com
DKG40BZ@chickenstolen.de
...
Observamos que en mailq.log hay direcciones "buenas" y "malas", bien manualmente o con alguna otra operación que se nos ocurra podemos quedarnos solamente con las "malas" para pasarle a postsuper. Podríamos eliminar de una tacada las direcciones propias del servidor, convirtiendo el cribado en algo más sencillo:
# cat mailq.log | grep -v server.com > mailq.log
Desde que tenemos el fichero con la lista de direcciones de correo "sobrante" podemos lanzar el siguiente comando, que buscará en mailq todas las referencias a esas cuentas, sacando el ID y procesándolo mediante postsuper:
# for i in `cat ~/mailq.log`; do `mailq | grep $i| cut -f1 -d* | postsuper -d -`; done
Una vez aplicados estos pequeños trucos la cola debería haberse limpiado bastante y lo que es más importante, en mucho menos tiempo que si vamos procesando los correos uno a uno.

Todo depende de las manos del administrador y de su capacidad de filtrado con las cuentas, pero realmente... ¿qué sistema no depende de un administrador?. Más sencillo sería un postsuper -d ALL aunque apuesto a que más de uno tendría cargo de conciencia.

freebsd postfix mailq postsuper mta

]]>
Fri, 26 Oct 2007 13:39:24 +0200
FreeBSD: Arrancando Postfix http://www.userlinux.net/noticia.1202.php http://www.userlinux.net/noticia.1202.php#comments http://www.userlinux.net/noticia.1202.php sistemas bsdfreebsdmtamailserver Hay circunstancias en las que un problema no se resuelve de la forma más eficiente. Suele ser bajo presión, cuando las cosas no se ven del todo claras y -sin motivo lógico- acaba funcionando con la condición no escrita de no tocarle más.

Algo así pasó hace tiempo en una FreeBSD, intentando reiniciar el servicio de correo (Postfix) no atendía a razones:
# /usr/local/etc/rc.d/postfix start
#
Rabia e impotencia se unían a la presión de tener colgado un servicio de varios cientos de clientes, indagando -deprisa y corriendo- por la sintaxis de postfix al final se solucionó con un inadecuado:

# postfix start
postfix/postfix-script: starting the Postfix mail system
#
Y ya sabeis lo que pasa cuando algo funciona, se repite hasta la saciedad por si las moscas rompe de alguna otra manera. Vicios que tiene uno. Hoy ya con más calma y razonando el problema me he dado cuenta de que en /etc/rc.conf no existía ninguna variable para arrancar postfix:
# echo postfix_enable="YES" >> /etc/rc.conf
Ahora el sistema ya me hace caso cuando quiero usar el script del daemon. Empanadas que tiene uno de vez en cuando pero... más vale tarde que nunca.

PD: Esta entrada se ha escrito en formato nota mental, como recordatorio para posteriores ocasiones.

bsd freebsd mta mailserver

]]>
Wed, 17 Oct 2007 14:27:51 +0200
Courier Authlib (de nuevo) http://www.userlinux.net/noticia.1193.php http://www.userlinux.net/noticia.1193.php#comments http://www.userlinux.net/noticia.1193.php sistemas freebsdcourierupdate Increible, o como diría Andrés Montes: "dos de dos!... jugón!". Segunda actualización fuerte en la misma máquina y de nuevo falla el mismo paquete: courier-authlib.

Aunque esta vez he leido y repasado el /usr/ports/UPDATING creo que a alguien se le ha ido la mano con el principal fichero de configuración. Ahora la actualización machaca tus configuraciones y coloca unas por defecto. Cierto es que antes genera una copia de seguridad pero solo faltaría que se quedara tan ancho.
# ls -flash /usr/local/etc/authlib/authmy*
10 -rw-------   1 courier  courier   8.3K Oct  3 16:45 authmysqlrc
 2 -rw-------   1 courier  courier   521B Nov 17  2006 authmysqlrc.bak
Nada que cp/mv no arreglen pero aún así resulta molesto perder el control de esta forma. Tirón de orejas para oliver@freebsd.org ;).

freebsd courier update

]]>
Wed, 03 Oct 2007 17:00:04 +0200
Arreglando pkgdb http://www.userlinux.net/noticia.1192.php http://www.userlinux.net/noticia.1192.php#comments http://www.userlinux.net/noticia.1192.php sistemas freebsdpkgdbportupgrade Hay veces que FreeBSD también juega malas pasadas. Este ha sido el caso de una máquina dejada en el olvido. Estoy intentando recuperar su uso y ponerla al día. Me gusta utilizar portupgrade para estas tareas de mantenimiento, con lo que, -después de un make update- al hacer un listado de los paquetes que necesitaban actualizarse procedo con uno de ellos:
# portupgrade ruby-1.8.5_4,1
[Updating the pkgdb (format:bdb_btree) in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected
file type or format -- Invalid argument; rebuild needed] [Rebuilding the pkgdb
(format:bdb_btree) in /var/db/pkg ... [Updating the pkgdb (format:bdb_btree) in /var/db/pkg ... /var/db/pkg/pkgdb.db:
unexpected file type or format -- Invalid argument; rebuild needed]
[Rebuilding the pkgdb (format:bdb_btree) in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Invalid 
argument: Cannot update the pkgdb!]: Cannot update the pkgdb!]
Command failed [exit code 1]: /usr/local/sbin/pkgdb -aFOQ
Vaya, era previsible tener algo roto después de tanto tiempo. A ver si obtenemos más información de lo que ocurre realmente:

# pkgdb -aFOQ
[Updating the pkgdb (format:bdb_btree) in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Invalid argument; rebuild needed] [Rebuilding the pkgdb (format:bdb_btree) in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Invalid argument: Cannot update the pkgdb!]: Cannot update the pkgdb!]
Parece que falla la base de datos de paquetes (pkgdb.db), intentamos forzar su recuperación:
# pkgdb -F
--->  Checking the package registry database
[Updating the pkgdb (format:bdb_btree) in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Invalid argument; rebuild needed] [Rebuilding the pkgdb (format:bdb_btree) in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Invalid argument: Cannot update the pkgdb!]: Cannot update the pkgdb!]
Sin éxito. Pues a lo bruto. Hacemos copia de seguridad de INDEX-6.db y pkgdb.db y procedemos a la actualización manual (make, make install...) de portupgrade, ruby-bdb y db4 (el gestor de base de datos de paquetes):
# mv /usr/ports/INDEX-6.db --> INDEX-6.db.org
# mv /var/db/pkg/pkgdb.db --> pkgdb.db.org
# pkg_delete portupgrade-2.3.1,2
# pkg_delete ruby18-bdb-0.6.2
# pkg_delete ruby18-bdb1-0.2.2
Es posible que nos advierta de dependencias insatisfechas en el borrado de alguno de estos paquetes, no nos preocupamos demasiado puesto que su eliminación solo será temporal. De necesitarlo, forzamos (-f) su desinstalación:
# pkg_delete db41-4.1.25_4
pkg_delete: package 'db41-4.1.25_4' is required by these other packages
and may not be deinstalled:
amavisd-new-2.4.3_1,1
p5-BerkeleyDB-0.31

# pkg_delete -f db41-4.1.25_4
pkg_delete: package 'db41-4.1.25_4' is required by these other packages
and may not be deinstalled (but I'll delete it anyway):
amavisd-new-2.4.3_1,1
p5-BerkeleyDB-0.31
Ahora reinstalamos portupgrade a la antigua usanza y desde cero (make clean para borrar antiguas compilaciones y configuraciones). Seleccionamos BDB4 de nuevo como backend de datos (¡veis como era temporal!). Y por último recomponemos de nuevo la base de datos de paquetes (pkgdb -F):
# cd /usr/ports/ports-mgmt/portupgrade
# make clean
# make config
  [X] BDB4  Use Berkeley DB >=2 as backend 
# make
# make install
# pkgdb -F
Finalmente ya estamos en disposición de volver al proceso de instalación/actualización del software obsoleto:
# portupgrade ruby-1.8.5_4,1
Imagino que habrá múltiples formas - y más simples- de recomponer este error, yo lo he hecho así ;).

freebsd pkgdb portupgrade

]]>
Wed, 03 Oct 2007 10:52:34 +0200
CVS: primeros pasos http://www.userlinux.net/noticia.1171.php http://www.userlinux.net/noticia.1171.php#comments http://www.userlinux.net/noticia.1171.php sistemas bsdopenbsd Hay quien dice que el uso de un servidor de versiones cuando el número de desarrolladores tiende a uno es injustificado, es posible que tengan razón pero llevo algunos años con la doble tarea -programar y versionar- y creo adecuado delegar responsabilidades en algo más fiable que yo.

Así que he tomado la decisión de probar CVS. Antes de ir corriendo a por unos algodones para los oidos intentaré explicar el motivo de usar estas siglas y no otras. Lo primero que se me ocurre es que OpenBSD lo trae de serie. ¡Correcto! la máquina que versionará mi código fuente es un pez globo. Entiendo que pueda parecer demasiado cómodo, pero para no haber usado nunca un sistema de control de versiones y poder evaluar la utilidad del mismo es más que suficiente.

A diferencia de casi cualquier otro software servidor, no ha sido doloroso ponerlo en funcionamiento, tres sencillas órdenes. Primero creamos el directorio donde irán nuestros módulos (proyectos), lo acomodamos con permisos generosos e iniciamos el repositorio:
# mkdir /home/cvs
# chown -R cvs:cvs /home/cvs
# cvs -d /home/cvs init
Del lado del cliente el asunto tampoco se complica en exceso siguiendo una cierta lógica. Las variables de sesión son indispensables para un uso correcto así que primero exportamos el directorio de trabajo del servidor y luego obligamos a CVS a conectrase mediante ssh:
# export CVSROOT=:ext:cvs@servidor:/home/cvs/
# export CVS_RSH=/usr/bin/ssh
Ahora tendríamos que hacer el commit inicial del código fuente, base del proyecto sobre el que trabajaremos, para ello y dentro del directorio donde tengamos el código haremos:
# cvs import -m "Commit Inicial" proyecto1 cvs start
Automáticamente se conecta a cvs@servidor y sube a /home/cvs/proyecto1/ la primera revisión de código fuente. Una vez hecho ésto debemos borrar (o cambiar de ubicación) el fuente del lado cliente para bajar la versión ya versionada -valga la redundancia- que acabamos de subir:
# cvs co proyecto1
Sencillo pero algo lioso, a partir de aquí ya podemos editar y trabajar en cliente para commitear los cambios sin temor:
# cvs ci proyecto1
Log message unchanged or not specified
Checking in cake/app/app_controller.php;
/home/cvs/cake/app/app_controller.php,v  <--  app_controller.php
new revision: 1.2; previous revision: 1.1
done
#
Referencias:

bsd openbsd

]]>
Mon, 03 Sep 2007 17:58:54 +0200
Dudando por un nuevo muro http://www.userlinux.net/noticia.1160.php http://www.userlinux.net/noticia.1160.php#comments http://www.userlinux.net/noticia.1160.php sistemas obsdbsdmuro Es posible que sea el momento adecuado de hacer reflexión y volver a levantar el muro. Me refiero a la máquina más importante de la red local, la que reparte conexión, filtra y se come los deshechos orgánicos del resto del mundo.

Reciclemos, en dicha máquina hay varios servicios que llevan 1 año -desde la visita del amigo Juanjo- en funcionamiento y no se han explotado demasiado, léase ftpd, proxy e incluso httpd. Otros -servicios/aplicaciones- como symon, symux, snort y cacti serán caso de estudio, porque o no se han acabado de configurar eficientemente o no se están usando como debieran.

Por un lado me apetece actualizar a OpenBSD-4.1, pero por otro lado pAvL0 -sin enlace todavía- me ha estado hablando maravillas de SmoothWall (aunque a mi me tiren más pfsense y m0n0wall).

Finalmente siempre cabe la -lazy- posibilidad de dejar todo como está haciendo hincapié en los servicios "a medias" y la conexión wireless. Dependerá del tiempo, del espacio y de las sensaciones cósmicas que reciban mis mermados sentidos.

obsd bsd muro

]]>
Fri, 20 Jul 2007 10:49:08 +0200
Snort + Base en OpenBSD http://www.userlinux.net/noticia.1112.php http://www.userlinux.net/noticia.1112.php#comments http://www.userlinux.net/noticia.1112.php sistemas baseopenbsd Snort es uno de los sistemas de detección de intrusos (IDS) más populares. Base es una de sus múltiples herramientas de análisis básico y OpenBSD es uno de los sistemas operativos más seguros. Haremos una instalación básica para guardar todas las alertas en base de datos (MySQL) y veremos los primeros resultados.

Antes de nada un poco de teoría de Sistemas de detección de intrusos, tipos y características...

IDS, HIDS

Los IDS, en principio, solo capturan alertas ocurridas en el host local donde están instalados. Aunque, por extensión, todos los Sistemas de Intrusion, del tipo que sean, son tambien llamados IDS:
  • IDS: Intrusion Detection System
  • HIDS: Host Intrusion Detection System
  • NIDS: Network Intrusion Detection System
Estos sistemas detectan alertas snifando el tráfico que pasa por su tarjeta de red. Por lo que si son colocados en los lugares correctos (p.e. los firewalls, gateways etc) nos detectan los ataques producidos a cualquiera de los hosts de nuestra red. Los DIDS (Distributed Intrusion Detection System) son NIDS donde los sensores que detectan y recolectan información están distribuidos en diferentes puntos/hosts en la red. Snort también puede actuar como NIDS. (leer más).

Instalación de Snort

Usaremos binarios puesto que la máquina es bastante obsoleta y no queremos sufrir un infierno compilando. Como podeis comprobar, se trata de una OpenBSD-3.9:
# pkg_add -r ftp://ftp.openbsd.org/pub/OpenBSD/3.9/packages/i386/snort-2.4.3-mysql.tgz
snort-2.4.3-mysql:pcre-6.4p1: complete
snort-2.4.3-mysql: complete
--- snort-2.4.3-mysql -------------------
An up-to-date set of rules is needed for Snort to be useful as an IDS.
These can be downloaded manually or net/oinkmaster can be used to
download the latest rules from several different sources.

It is recommended that snort be run as an unprivileged chrooted user.
An _snort user/group and log directory has been created for this
purpose.  You should start snort with the following options to take
advantage of this:
        -u _snort -g _snort -t /var/snort
and if you want to log:
        -l /var/snort/log
#
Bajamos las RULES de la versión 2.4 (usuarios no registrados, para probar):
# wget -c http://www.snort.org/pub-bin/downloads.cgi/Download/vrt_pr/snortrules-pr-2.4.tar.gz
# mkdir -p /etc/snort/rules
# mv snortrules-pr-2.4.tar.gz /etc/snort/rules/
# tar xfvvz snortrules-pr-2.4.tar.gz  

Configuración MySQL

Conectamos con mysql para crear base de datos, usuario y demás (ojo con el socket si lo tenemos configurado para httpd chrooted):
# mysql -u root --socket=/var/www/var/run/mysql/mysql.sock -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7 to server version: 5.0.22

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> CREATE DATABASE snort;
Query OK, 1 row affected (0.29 sec)

mysql> GRANT INSERT, SELECT ON snort.* to snort@localhost;
Query OK, 0 rows affected (0.53 sec)

mysql> SET PASSWORD FOR snort@localhost = PASSWORD('password');
Query OK, 0 rows affected (0.05 sec)

mysql> GRANT CREATE, UPDATE, INSERT, DELETE, SELECT ON snort.* TO snort@localhost;
Query OK, 0 rows affected (0.00 sec)
Importamos la estructura de la base de datos. En OpenBSD no instala ningún archivo donde importarla, con lo aquí dejo una copia: create_mysql.gz.
# gunzip -d create_mysql.gz
# mysql -u root --socket=/var/www/var/run/mysql/mysql.sock -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7 to server version: 5.0.22

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> USE snort;
Database changed
mysql> source create_mysql;
Query OK, 0 rows affected (0.27 sec)
Query OK, 1 row affected (0.11 sec)
Query OK, 0 rows affected (0.04 sec)
Query OK, 0 rows affected (0.02 sec)
Query OK, 0 rows affected (0.00 sec)
...
mysql>

Configuración Snort

En OpenBSD el fichero de configuración principal de Snort se encuentra en /etc/snort/snort.conf, donde tendremos que indicarle al menos que guarde las alertas y los logs en MySQL, parámetros de red y poco más:
var HOME_NET 192.168.0.0/24

var DNS_SERVERS $HOME_NET
var SMTP_SERVERS $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var TELNET_SERVERS $HOME_NET
var SNMP_SERVERS $HOME_NET

var RULE_PATH ../rules/rules

output database: log, mysql, user=snort password=password dbname=snort host=localhost
output database: alert, mysql, user=snort password=password dbname=snort host=localhost

Arrancando Snort

Recomiendan:
# snort -bDI -A fast -c /etc/snort/snort.conf
  • -b –> Log paquetes en formato binario ( tcpdump -r file)
  • -D –> Modo daemon
  • -I –> Indica la interfaz por la que llego el paquete
  • -A –> Tipo de alerta ( fast= una linea en el fichero alert)
  • -c –> Fichero de reglas
Aunque mi opción ha sido más simple (con un ojo siempre en /var/log/daemon y /var/log/messages por posibles problemas de permisos, logs...):
# snort -bDI -A fast -c /etc/snort/snort.conf

Instalando BASE

Basic Analysis and Security Engine. Desgargamos la última release (19.04.07) dentro del DocumentRoot y descomprimimos:
# wget -c http://kent.dl.sourceforge.net/sourceforge/secureideas/base-1.3.5.tar.gz
# tar xvvz base-1.3.5.tar.gz
Una vez dentro del directorio, encontramos en sql/ lo necesario para montar las tablas que BASE usará para sus propios análisis. Agregaremos el esquema a la base de datos snort anteriormente creada:
# cat sql/create_base_tbls_mysql.sql | mysql -u root --socket=/var/www/var/run/mysql/mysql.sock  -D snort -p
# mysql -u root --socket=/var/www/var/run/mysql/mysql.sock -p
...
   mysql> show tables;
+------------------+
| Tables_in_snort  |
+------------------+
| acid_ag          |
| acid_ag_alert    |
| acid_event       |
| acid_ip_cache    |
| base_roles       |
| base_users       |
| data             |
| detail           |
| encoding         |
| event            |
| icmphdr          |
| iphdr            |
| opt              |
| reference        |
| reference_system |
| schema           |
| sensor           |
| sig_class        |
| sig_reference    |
| signature        |
| tcphdr           |
| udphdr           |
+------------------+
Vemos que se han creado nuevas tablas con el prefijo acid, esto es porque BASE está basado en ACID -muerto o desactualizado desde el 2003-.
En las instrucciones hay que resolver algunas dependencias de BASE para que funcione correctamente, ADODB es una de ellas:
# wget -c http://puzzle.dl.sourceforge.net/sourceforge/adodb/adodb494.tgz
# tar xfvvz adodb494.tgz
Image_Graph la otra:
# wget -c http://download.pear.php.net/package/Image_Graph-0.7.2.tgz
# wget -c http://pear.php.net/get/Image_Canvas-0.3.0.tgz
# wget http://pear.php.net/get/Image_Color-1.0.2.tgz
Una vez hemos descargado Image_Graph de Pear lo descomprimimos en el directorio Images/ que previamente tendremos que crear, quedando de la siguiente forma:
 base/
   |- Images/
   |- Canvas/
   |- Graph/
   |- docs/
   |- tests/
   |- Canvas.php
   |- Color.php
   |- Graph.php
El siguiente paso será acceder vía web al BASE recién instalado: http://localhost/base/ -donde proceda- y seguir las instrucciones:
Snort Base
Snort Base
Snort Base
Snort Base
Snort Base
Snort Base
Nota: He tenido que tocar más de una vez durante la instalación el archivo base_conf.php para editar la variable $DBlib_path del adodb dependiendo del punto de la instalación en el que te encuentres. Al final ha quedado $DBlib_path = ‘adodb/’;

Referencias

base openbsd

]]>
Mon, 23 Apr 2007 12:54:15 +0200
Bowlfish http://www.userlinux.net/noticia.1093.php http://www.userlinux.net/noticia.1093.php#comments http://www.userlinux.net/noticia.1093.php sistemas obsdbsdflashdevicesrsidenotes http://www.kernel-panic.it/software/bowlfish/

OpenBSD en dispositivos flash

obsd bsd flash devices rsidenotes

]]>
Mon, 02 Apr 2007 13:21:26 +0200
Secure by default http://www.userlinux.net/noticia.1081.php http://www.userlinux.net/noticia.1081.php#comments http://www.userlinux.net/noticia.1081.php sistemas openbsdsecuresecbugkernelbufferoverflow OpenBSD es un Sistema Operativo cuya filosofía (tanto de uso como de desarrollo) se centra en la seguridad. Theo de Raatd ha descubierto recientemente el segundo bug remoto en la instalación por defecto durante los últimos 10 años.

Se trata de un buffer overflow del kernel en alguna parte del código (mbuf) que toca IPv6, pudiendo deshabilitarse fácilmente en PF a través de una regla 'block in inet6' o aplicando el correspondiente parche en sys/mbuf.h.

Ahora el slogan: OpenBSD, toda una garantía de seguridad.

openbsd secure sec bug kernel buffer overflow

]]>
Wed, 14 Mar 2007 17:16:42 +0200
Muchos grupos, muchos permisos http://www.userlinux.net/noticia.1063.php http://www.userlinux.net/noticia.1063.php#comments http://www.userlinux.net/noticia.1063.php sistemas bsdpermisoschmodchownchgrpaclsetfaclbofhadmin 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).

Suponiendo cuatro grupos de usuarios: curritos, usuarios, jefes y jefazos y un archivo informe.xml queremos el siguiente esquema:
grupos			permisos
--------------------------------
curritos:		---
usuarios:		r--
jefes:			rw-
jefazos:		rwx
Por muchas combinaciones que pudiéramos pensar, entre grupos o algo así, siempre se puede aumentar el grado de complejidad agregando más grupos con distintos permisos. El caso es que la pregunta era buena, demasiado como para que quede sin responder. Como ¿buen? docente, la apunté para buscar soluciones y esto fue lo que encontré (thanks Wu):
# mkdir testfolder
# setfacl -m group:group1:rwx,group:group2:r-x,group:group3:---,other:---,mask:rwx testfolder/
¡Listas de acceso, claro!. Aunque se limita a sistemas de archivos capaces de usarlas (ext3, xfs...), esa podría ser una buena solución al problema planteado. En distribuciones deb like el comando setfacl se encuentra en el paquete acl (apt-get install acl)... el resto todavía está por probar.

bsd permisos chmod chown chgrp acl setfacl bofh admin

]]>
Wed, 07 Feb 2007 10:38:36 +0200
Cambios de portupgrade http://www.userlinux.net/noticia.1062.php http://www.userlinux.net/noticia.1062.php#comments http://www.userlinux.net/noticia.1062.php sistemas freebsdportupgradesearch 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:

# make fetchindex
/usr/ports/INDEX-6.bz2                        100% of  869 kB  118 kBps
# cd /usr/ports/ ; make search name=portupgrade | grep Path
Path:   /usr/ports/ports-mgmt/portupgrade
Path:   /usr/ports/ports-mgmt/portupgrade-devel
#
Venga va, la próxima vez ya sé donde buscar. Los hombres sabios aprenden con los errores que otros cometen, los tontos con los propios.

freebsd portupgrade search

]]>
Tue, 06 Feb 2007 17:07:48 +0200