DD-WRT en Linksys WRT54GL

Hoy me ha llegado un router WRT54GL de FON (Neutro) que ya he registrado como fonero y flasheado. He ido a la web del firmware DD-WRT a descargar la imagen mini, metérsela al router y luego proceder a meter la versión con VPN (Por probar a ver que tenía). Es como tener una Smoothwall o IPCop (No es comparable con MonoWall) pero en un cacharro más pequeño, con 16 MB de RAM y 216 MHz. Es sencillamente una maravilla y su alcance es cojonudo. Además sus antenas son desmontables (Ambas) y puedo conectar otras antenas.

Que me haya aprovechado de la promoción de FON, no quiere decir que no libere mi wifi, eso sí, por ahora no. Cuando tenga todo correctamente montado compartiré mi línea, algo que espero no se alargue mucho.

Como siempre tuve pensado, restringiré la salida por la WLAN, solamente a HTTP, HTTPS, SMTP, POP3, Jabber, IRC y quizá si alguien me convence, MSN. El servidor DNS estará en mi casa, escuchando en todas las interfaces internas y montaré un sistema de colas en el gateway para que no se pasen de listos.

Ya veré como lo monto todo. Tendré que hacerme un esquema. Principalmente, la WLAN estará en otra red, así como a medio plazo los servidores en una DMZ, dejando esta máquina (Cliente) en otra red.

Pero ya que me pongo a hablar de mis servidores os contaré lo que tengo pensado hacer también a medio plazo. Actualmente tengo muchas (2 o más) máquinas, unas Gentoo, otra Debian… y empieza a ser cansino mantener los servicios, sobretodo cuando tienes mejores cosas que hacer. He decidido que si me encuentro con ganas, por el verano montaré en el Celeron 900 MHz una FreeBSD 6.1 con Apache, Servidor FTP (He de mirar vsftpd contra MySQL), Postfix para SMTP, Courier para POP3 e IMAP, etc. De ese modo tengo una máquina decente para probar sistemas operativos en entorno real con hardware de verdad, dejando de lado las máquinas virtuales. Como ya he dicho en post anteriores tengo ganas de pillar por banda un Plan9 o Solaris. Quizá me ponga con Solaris, por entretenimiento y por lo didáctico del asunto.

Por lo tanto, la nueva estructura será algo así:

WAN –> Modem –> Gateway OpenBSD –> Switch D-Link –> Red

La red como dije antes la estructuraré en:
Clientes: 10.0.0.0/30
Servidores: 172.24.0.0/28
Clientes:192.168.0.0/24

Lo pongo en diferentes clases no porque no sepa crear subredes con mascara de longitud variable, sino por el reconocimiento a primera vista.

Aquí surge un problema, de mi máquina cliente no puedo acceder a los servidores porque están en otra red y claro, enrrutar ambas hace que el invento pierda la gracia, por lo que tendré que tener un teclado y pantalla disponibles.

Ya os iré contando. De momento, estoy abierto a nuevas ideas.

Escrito por Gura 19.Jun.06 Clases o cursos, Debian, FreeBSD, Gentoo, Hardware, Plan9, Redes, Servidor, Solaris Leer más Comentarios (15)

OpenBSD sobre la cuerda floja

Que oportuno . Un sistema operativo robusto como es, al cual ya cogí mi cariño, está, según ésta noticia que me pasó Solusan, en muy mala situación económica, y cuando hablo de mala no es de no tener pasta sino de tener pérdidas. Cuarenta mil (40000) dólares en los últimos 2 años. Cierto es que cuando está disponible por FTP no compras los CD’’s (Yo el primero, pues tengo otras cosas en que gastar esos 45 € que cuesta, sin contar que pago por cosas que no usaré, como otras arquitecturas). Podría pedir unas camisetas, que las hay guapas, pero pagaría más de portes que por las camisetas practicamente, y eso me jode.

Quien sabe, quizá pida unas camisetas como ésta y ésta otra.
Necesitan ayuda y los que lo usamos deberíamos hacer lo posible por que tire para delante, aunque claro está que quienes más deberían preocuparse son, a quienes cuyo dinero y tiempo afecta este proyecto.

Agur

Escrito por Gura 25.Mar.06 *BSD, OpenBSD, Sistemas Leer más Comentarios (2)

Un AP bajo FreeBSD con una wifi de chip Atheros y un PC viejo

Hoy me dió por mirar los blogs del topic de #lucux y llegué a uno interesante, donde trataban como montarse un AP con FreeBSD y una tarjeta de chip Atheros que Celso me recomendó y me aseguró que funcionaba en modo maestro bajo el kernel Linux.
Éste es el post y habría que comprobar si sirve para OpenBSD, una pena que no tenga necesidad de ello.
Como ya comenté la otra posibilidad es el modo ad-hoc, aunque no me convence mucho.
Hay quien sostiene la idea que mejor comprar un equipo (Un cortafuegos Nokia por ejemplo) que te lo haga, pero nose, para una empresa veo más económico y escalable una máquina con un SO robusto como puede ser GNU/Linux o *BSD. Es algo en lo que Rastreador y yo coincidimos, peor claro, necesitas a alguien con conocimientos para tenerlo al día.

Volviendo al tema del Access Point…
¿Alguien sabría decirme? ¿Experiencias positivas o negativas?

Ahora sí, buenas noches.

Escrito por Gura 17.Mar.06 *BSD, FreeBSD, GNU/Linux, OpenBSD, Redes Leer más Comentarios (3)

Entrevista a Theo de Raadt

Hoy nrktk nos ha pasteado el link de la entrevista a Theo de Raadt en The Business Show. También disponéis de otro vídeo, que por su peso, no he descargado.
Y hablando de OpenBSD, para quien me lea y le interese, asíduos del canal #BSDes en FreeNode han comenzado un proyecto para traducir y mantener la documentación de OpenBSD en castellano. Si queréis echar un cable podéis visitar su web. ¡Ánimo!

Agur

Escrito por Gura 12.Mar.06 *BSD, OpenBSD Leer más Comentarios (0)

Actualizando OpenBSD

Si no os acordáis, llevo unos meses queriendo terminar algo que empecé, el cortafuegos con OpenBSD. Para quien venga de Linux como yo, que he usado solamente 2 distribuciones las cuales son SuSE y Gentoo. SuSE tiene YaST, exactamente YOU (YaST Online Update) por el cual te podías bajar actualizaciones de seguridad y algunos fixes. Si querías nuevas versiones, o instalabas una SuSE más nueva, la cual traía software más reciente, o como hace Rastreador, que ha ido metiendo versiones nuevas sobre, si no recuerdo mal, SuSE 9.1.

Hace unos meses, cuando vi el proyecto OpenSuSE, decidí probar Gentoo. Aquí tienes 2 ramas, la estable y la inestable. Yo uso la estable y tengo paquetes de la inestable, como por ejemplo en KDE, interfaces gráficas, etc… También cabe destacar los GLSA (Gentoo Linux Security Advisories), que simplemente, si hay una versión vulnerable la actualiza a una superior. Es lo único que no me gusta del todo si la usase como servidor, ya que estoy acostumbrado a Debian Sarge y su política de actualizaciones.

Y a lo que iba, OpenBSD. OpenBSD no distribuye ISO de sus CD”’’s, así que tendremos que hacerla nosotros mismos. Una vez instalada tenemos una OpenBSD 3.8-RELEASE, que es la que tiene los CD”’’s. Pero eso no es una rama, no se actualiza, se liberó y punto. Éste es el momento en el que tenemos que elegir que rama escoger, si la -STABLE o la -CURRENT. Si queremos un sistema en producción, claramente actualizaremos a -STABLE.

Los fallos de seguridad del sistema base los tenéis aquí y los de paquetes de la rama STABLE aquí.

Como veis hay 3 fallos de seguridad. Hoy he encontrado la forma más cómoda (en mi opinión) de actualizar el sistema base.

Actualizamos las fuentes del sistema al patch brach OPENBSD_3_8:

*default host=rt.fm
*default base=/var
*default prefix=/usr
*default release=cvs
*default delete compress

OpenBSD-src tag=OPENBSD_3_8

Eso lo guardamos en, por ejemplo, ~/supfile.

Ahora montamos el CD y extraemos el paquete src.tar.gz a /usr/src y sys.tar.gz a /usr/src/sys. Una vez descomprimido ejecutaremos:

cvsup -g -L 2 ~/supfile

Nota: La ooción “-L 2″ es el nivel de debug del proceso.

Cuando termine tendremos un /usr/src actualizado.

Aún no hemos actualizado a STABLE, así que con todo ya preparado seguimos la guía. Compilamos nuevo kernel, lo cambiamos, reiniciamos con el nuevo y luego recompilamos binarios.

Nota: A la hora de compilar es imprescindible tener instalado el paquete misc.tgz que viene en el CD. Si no es así, lo descomprimís en el raíz.

Ahora tenemos la OpenBSD 3.8-STABLE. Revisamos que los paquetes estén en su última versión disponible y lo ponemos a funcionar de lo que nos dé la gana, supongamos que de cortafuegos.

Pero claro, no existe nada perfecto, y como hace unos días, un bug en la función scp de SSH. Ahora nos planteamos como actualizar…

• Ejecutar de nuevo cvsup -g -L 2 ~/supfile y recompilar todos los binarios del sistema y si es el kernel, el kernel
• O la otra opción, que como no hay muchos fallos, no será caótico. La alternativa es bajarse los .patch y aplicarlos

Yo he optado por la segunda opción:

wget patch
less 005_ssh.patch

(salida)
Apply by doing:
cd /usr/src
patch -p0 > 005_ssh.patch

And then rebuild and install ssh:
cd usr.bin/ssh
make obj
make
make install

Pues esas son las instrucciones, bien claras.

La primera opción hubiese sido una muñonada, recompilar todo el sistema a lo tonto, para que por ejemplo luego casque algo. De este modo lo único que tenemos que hacer es estar pendientes de los fallos de seguridad que aparecen, parchear el código fuente y fijarnos a qué afecta la vulnerabilidad, si a algún binario del sistema base o solo al kernel, y compilar.

Una vez recompilado en nuestro ejemplo SSH, mataremos sshd y volveremos a ejecutarlo. Si estamos en remoto lo más probable es que perdamos la conexión con el host. Se me ocurre una idea, que es programar un trabajo que se ejecute en 2 minutos, por ejemplo.

Otra cosa que me he pasado por alto es que Apache y Bien9, por ejemplo, forman parte del sistema base, es decir, si sale una vulnerabilidad tendremos que recompilarlo como hicimos ahora con ssh. Las versiones que trae OpenBSD son viejas, pero eso no es malo si cumple con tus necesidades, ya que al ser más viejas están más auditadas (Recordad que el sistema base es auditado, pero los paquetes es cosa del desarrollador no del equipo de OpenBSD). ¿Qué quiero decir con esto? Que mejor usar en lo posible lo que el sistema base nos brinda, si no es posible, los paquetes, y sino, los ports. También podemos recurrir al código fuente oficial del software en cuestión, pero bueno.

Si usáis ports, al igual que lo demás, tendréis que actualizarlos, para ello basta con añadir la linea:

OpenBSD-ports tag=OPENBSD_3_8

Entonces creamos el directorio /usr/ports (Porque no estoy seguro de si lo crea) y actualizamos.

Todo este código fuente y post ocupa espacio, así que una buena idea sería volcarlo mediante NFS en otra máquina con más capacidad de almacenamiento.

Con esto doy por concluido, cuando tenga un rato lo pondré en mi web.

Agur

Escrito por Gura 28.Feb.06 *BSD, Gentoo, OpenBSD, Sistemas, SuSE Leer más Comentarios (2)

Historia de los sistemas BSD

Mientras ojeaba Mononeurona me puse a leer un artículo muy interesante acerca de la historia de los sistemas BSD.

En 1969 la empresa AT&T encargo a Ken Thompson y Dennis Ritchie reducir el sistema operativo MULTICS para portarlo a los equipos más pequeños que la NASA utilizaba en sus misiones espaciales. A finales de ese año presentaron un sistema al que llamaron UNICS (UNiplexed Information and Computing Service) un ”emasculated Multics”. Nadie sabe en que momento UNICS paso a ser Unix, pero según cuenta la layenda urbana, una secretaria no supo como escribir lo que le dictaban y escribió Unix y el nombre así se quedo.
El profesor Bob Fabry de la universidad de California en Berkely fue uno de los primeros interesados en conocer Unix y pidió una copia a la Universidad de Purdue, donde Thompson y Ritchie trabajaban. Sin embargo el mainframe de Berkeley poseía unos controladores de disco duales que Thompson no había previsto y trabajando junto con el departamento de matemáticas de Berkeley agregaron el soporte que faltaba. Esto fue el inicio de un intenso periodo de colaboración entre Berkeley y Bell Labs (subsidiaria de AT&T) al grado que Thompson tomó un año sabático en California para seguir desarrollando a Unix. Bajo su guía varios profesores y estudiantes de Berkeley realizaron cientos de mejoras y extensiones al kernel de Unix.
La segunda versión de Unix apareció en 1972. Por esas mismas fechas Ritchie reescribió el lenguaje B, creando a C. La sexta edición de Unix se libera en 1975, junto al nuevo Bourne Shell. En 1977 el estudiante graduado Bill Joy colocó todas las mejoras hechas en Berkeley y lo llamó “Berkeley Software Distribution.” Al poco tiempo Joy había enviado más de treinta copias de BSD a varias universidades. Las copias incluían al nuevo editor que Joy había creado: vi. Sin embargo, las características de las terminales variaban mucho y Joy decido escribir un pequeño intérprete que dibujaba la pantalla según sus características y así nació termcap. En 1979 se lanzó la séptima edicion de Unix y la tercera de BSD: 3BSD.
Por esos tiempos, el ejército estadunidense estaba preocupado por la escasa interoperatibilidad entre las plataformas que conformaban sus sistemas a través del país. Se pensó diseñar un hardware específico pero luego de pensarlo otra vez decidieron unir sus equipos a nivel de software, Unix fue el elegido para ello debido a su portabiliad. Los encargados del proyecto se pusieron en contacto con Berkeley para fondear el proyecto. En 1981 se lanzó la versión 4BSD con más de 400 envíos a todo el mundo. En 1982 Joy anunciá que deja Berkeley para incorporarse al equipo de Sun Microsystems y comienza a desarrollar Solaris, un sabor de Unix basado en BSD.
En 1985 los investigadores de la universidad Carnegie-Mellon comienzan a desarrollar su propio Kernel, conocido como Mach Kernel, el cual tomó librerias, código e ideas de BSD, si bien desarrollo e introdujo conceptos propios en su implementación de Unix. Posteriormente el Mach kernel sería usado para los sistemas de la empresa NeXT, la cual, a su vez, fue comprada por Apple Computers en 1996. El Mach Kernel es la base del Mac OSX actual y existe un versión que puede descargarse gratuitamente (claro, sin el ambiente gráfico) llamado OpenDarwin.
En 1984 apareción 4.2BSD, con la cual se estrenaba el protocolo TCP/IP desarollado por la gente de Berkeley. Está versión de BSD fue quizás su mayor éxito vendiéndose miles de licencias, al grado de que las empresas comenzaron a migrar de Unix SysV al nuevo BSD pues poseía muchas facilidades de red y el nuevo sistema de archivos Berkeley Fast filesystem. Varias empresas comenzaron a acercarse a Berkeley para distribuir BSD por su cuenta.
Esto provoco una demanda de AT&T que tardo varios años en resolverse. Según Berkeley, el acuerdo de cooperación contemplababa el acceso al código fuente pero AT&T argumentaba que eso violaba sus derechos de autor pues en el código había secciones que le pertenecían. Todos los involucrados en el desarrolo de BSD tuvieron que testificar en el juicio y eso retrasaba el trabajo. Un grupo de desarolladores hicieron mejoras al kernel y lanzaron el primer NetBSD en 1993, poco tiempo después otro grupo lanzó FreeBSD. Por fin, en enero de 1994 el juez que llevaba el caso entregó una pequeña lista de archivos que debian reemplazarse de BSD y con ello la cuestión legal fue zanjada.
Theo de Raat, un talentoso y problemático desarrollador de NetBSD, tuvo problemas con otros miembros del equipo y por ello decidió comenzar su propio proyecto: OpenBSD. Este sistema operativo, se concentra en la portabilidad, el cumplimiento de normas y regulaciones, corrección, seguridad proactiva y criptografía integrada.

Agur

Escrito por Gura 24.Feb.06 *BSD, FreeBSD, NetBSD, OpenBSD, Sistemas Leer más Comentarios (2)

Al fin se encontraron 2 bugs

Era hora, al final, el día 5 de éste mes se encontraron dos vulnerabilidades en OpenBSD 3.8 lo que me dio la posibilidad de estrenarme con la recompilación del sistema. Recompilé el kernel GENERIC de nuevo y todo correcto, luego al recompilar los binarios me cascaba al compilar ncurses o similar dando un “Error code 1″. Todo se soluccionó visitando BSDForums donde mucha gente ya había tenido ese mismo problema. Ocurre por hacer una instalación muy pequeña y omitir el paquete misc38.tgz. Para instalarlo luego monté el CDROM y descomprimí en en raíz. Todo terminó bien. Ahora estoy recompilando el kernel sin soporte IPv6 y demás cosas que no necesito como soporte de audio, usb, tarjetas de red… etc

Ale mañana pa clase otra vez, agur.

Escrito por Gura 08.Jan.06 *BSD, OpenBSD, Sistemas Leer más Comentarios (1)

Como anillo al dedo, si señor

Hoy hablando con Baby en el IRC a las 5 de la mañana, me comentó algo sobre el router en modo bridged, que es diferente que tenerlo en monopuesto. Yo ahora lo tengo en monopuesto y como ella dijo:
Baby pero en monopuesto el router puede recibir ataques
Baby y en bridge no

Así pues, me dí cuenta que era verdad cuando recordé que a mi router tenía que matarles procesos como httpd y telnetd para que no tuviesen puertos a la escucha.

Así que visto el cambio que voy a hacer, he buscado por Google y he encontrando este cojonudísimo artículo, joder. Es que es… mi caso, igualito.

Así que ya tengo como dejarlo “perfecto” aunque la perfección no existe :). Malana me pondré a migrar a -stable.

Agur y hasta mañana, que me piro a sobar, el sueño aprieta.

Escrito por Gura 29.Dec.05 *BSD, OpenBSD, Redes, Sistemas Leer más Comentarios (0)

Instalando un nuevo cortafuegos

Bueno, ahora como cortafuegos tengo un viejete P100 con 1 GG de disco duro haciendo solo de cortafuegos, peor quiero cambiarlo, volver a la buena vida y tener en mi red Squid y una caché DNS.

La nueva máquina será un AMD K6-II con 192 de RAM y 12 GB de disco duro, uno de los cuales será destinado solamente a la caché del Squid. Bueno, lo primero:

¿Qué sistema operativo le pongo?
Creo que no hay dudas… Windows Server 2003 + ISA Server 2004 es el mejor. Me sale un 33% más barato que Linux, la instalación es un 70% más fácil, es mucho más seguro y además viene con IIS, que es un 276% más rápido que los servidores web de Linux, según cuentan algunas empresas que no tienen mejores cosas que hacer.

Dejando de lado las gilipolleces básicamente tenía que elegir entre Linux o no-Linux (*BSD, Hurd, Solaris, etc). He usado OpenBSD muy poco tiempo, también he usado muy poco FreeBSD y aunque no lo conozco tanto como Linux y por eso no obtendré un sistema tan seguro (Por ahora, ya profundizaré), usaré OpenBSD. ¿Por qué OpenBSD? Porque Linux tiene demasiados fallos y como un día leí en algún sitio, demasiados son 1 o más, y más que OpenBSD.

En fin, me he parado un rato leyendo unas cosas, acerca del ARP Poisoning y bueno, con un simple:

arpoison -i eth0 -d 10.0.0.3 -s 10.0.0.2 -t 00:40:F4:CE:8C:DD -r AA:BB:CC:DD:EE:EE

arpoison -i interface -d IP_Destino -s IP_Origen -t MAC_REAL_DE_LA_VICTIMA -r MAC_DE_MENTIRA

Si metemos las MAC a mano, teóricamnete sería invulnerable remotamente claro:

arp -i eth0 -s 10.0.0.2 00:11:2F:A6:EE:FF

He probado de nuevo con arpoison y sin resultado.

Bueno, Un artículo interesante.

A lo que iba, tengo que, sin desmontar todo probar el cortafuegos y todo, así que he pensado:

1. Con 2 tarjetas ISA de 10 mbps en el cortafuegos nuevo, tener conectado por cable directo a las bocas 4 y 5 del switch respectivamente.
2. En mi máquina, correr una máquina virtual. He pensado en Debian, en modo texto, con utilidades de dns, arp, monitor de red, y demás. Algún navegador como links2, también meteré wget y por otro lado, un servidor FTP, así pruebo el NAT y el modo pasivo. Creo que no se me olvida nada.
3. Ahora, la idea es, desde la máquina virtual generar tráfico que entre por al interface conectada a la boca 4 y salga por la 5 y de ahí al P100 y a internet. Eso sería la salida, osea, si funciona el NAT el tráfico sería correcto, pero quiero tener servicios tras el cortafuegos, así que desde mi máquina conectaré mediante ftp al cortafuegos nuevo, ocupándose éste de redirigir la petición a la máquina virtual. No hay más, por si os parece poco.

Agur

Escrito por Gura 28.Dec.05 *BSD, OpenBSD, Redes Leer más Comentarios (3)

NetBSD 3.0 publicada

Según leo en barrapunto NetBSD ha sacado su versión 3.0. Hacia pocos meses que salía la 2.1. No dejan de sorprendernos. Podéis leer más acerca d ela nueva versión aquí

Agur.

Escrito por Gura 24.Dec.05 NetBSD Leer más Comentarios (0)