[INTRO]
Continuando con la línea de estos mini-mini-howto, esta vez regreso a la escena con un pequeño documento para tener nuestro propio servidor de correo basado en Postfix (http://www.postfix.org). Postfix es un MTA (Mail Transfer Agent) que nace como una alternativa para sustituir al viejo y archi reconocido Sendmail (http://www.sendmail.org). ¿Qué cual es la diferencia entonces? Sendmail ha sido un MTA (al igual que Postfix) que ha evolucionado con el tiempo, inicialmente Sendmail fue un MTA que nació con muchas deficiencias, incluso aquellos geeks (like me) que han leído un poco sobre el tema, se acordarán del famoso gusano Morris (http://en.wikipedia.org/wiki/Morris_worm) el cual, entre otros atributos (que recomiendo lean), explotaba una vulnerabilidad de Sendmail. Incluso, durante aquella época, populaba un chiste entre los geeks el cual decía: "¿y cual es la nueva vulnerabilidad de Sendmail para hoy?". Bien, no es que Sendmail sea malo, por el contrario, como cualquier software, éste ha evolucionado con el tiempo y mejorado mucho más. Si algo hay que saber sobre Sendmail, es que es uno de los servidores de correo más utilizados en el mundo. De hecho, yo todavía tengo que seguir manteniendo y administrando bastantes servidores de correo basados en Sendmail.
::[INTRO]::
![]()
Bien, aquí nos encargaremos de cambiar el nombre del host de una máquina que ejecuta Linux Red Hat 9.0 y no voy a utilizar el comando hostname, lo que vamos hacer es editar el archivo en donde se establece este parámetro cuando lá máquina sube.
::[HOWTO]::
Para cambiar el nombre del host de un Red Hat 9.0 de manera permanente, edite el archivo /etc/sysconfig/network, y cambie el valor de la variable HOSTNAME por la de su agrado.
Aquí está el ejemplo del contenido de ese archivo:
NETWORKING=yes GATEWAY=200.1.70.11 HOSTNAME=servidor.foo.com
Incluso si somos buenos observadores nos damos cuenta que allí cambiando el valor de la variable GATEWAY podemos establecer el gateway por defecto de este host.
::[FINAL]::
Que fácil ¿cierto?
::[INTRO]::
En este mini-mini-howto la película nos va de como saber el tamaño en Bytes, en Megas o en "Galllinas" que ocupa un directorio de nuestro sistema de archivos POSIX (hablo de Linux) y todo su contenido.
::[HOWTO]::
Para ver el tamaño de un directorio de manera recursiva ejecute el comando du.
Algunos ejemplos interesantes:
::[INTRO]::
Simple, se trata de configurar un router 1603 R de Cisco para que reciba una llamada de otro Router Cisco a través de un enlace ISDN. Aquí no voy a entrar en los pormenores de la configuración, solo publico este ejemplo como consulta rápida.
::[HOWTO]::
Bajo los siguientes supuestos estoy trabajando:
Al instalar Drupal en la misma maquina en donde tenemos configurado Squirrelmail, al intentar entrar a Squirrelmail, es posible que recibamos el siguiente error:
Fatal error: session_start(): Failed to initialize storage module: user (path: /var/lib/php/session) in /usr/share/squirrelmail/functions/global.php on line 333
Para corregirlo debe procederse de la siguiente manera:
::[INTRO]::
Después de tanto tiempo de haber estado trabajando con FreeSwan como implementación de IPSec sobre Linux para el tema de VPNs (LAN-to-LAN) no se nos había ocurrido algo tan simple para solucionar el problema relacionado a continuación:
Cuando un paquete IP que nace en el VPN Gateway, y va con destino hacía la otra LAN con la que se establece el túnel VPN, el paquete IP se arma en el campo "source address" con la dirección IP pública que tenga asignado el VPN Gateway, lo cual genera un problema de enrutamiento porque este paquete no se va por el túnel IPSec. La forma correcta del paquete debe contener en el campo "source address" la dirección IP privada del VPN Gateway para que el paquete se enrute por el túnel y no por otro lado.
::[PROBLEMA Y SOLUCIÓN]::
Los que hayan tenido la experiencia de trabajar con FreeSwan como implementación de IPSec en Linux, seguro habrán tenido que hacer un ping desde el VPN Gateway dirigido a la LAN del otro extremo del túnel, forzando al PING para que se genere con la dirección IP privada del VPN Gateway y no con la dirección IP pública.
Veamos el caso gráficamente:

::[INTRO]::
Puede que sea demasiado trivial, pero si no se quieren romper el coco conviertiendo de bytes a megas o a gigas al mirar los FileSystems de nuestro sistema Linux, les recomiendo una salida "humana" del comando df.
::[HOWTO]::
Para ver los FileSystems en las unidades de medida de megas, gigas o teras o lo que sea, ejecute:
# df -h
Lo cual genera una salida como la que muestro aquí:
::[INTRO]::
Continuando con esta serie de mini-mini-howto's, voy a explicar como agregar seguridad básica a un directorio Web para poder ver su contenido con previa autenticación. Vamos en este ejemplo a crear una autenticación básica sobre un directorio Web particular, por ejemplo, al solicitar un URL como http://www.cualquier.dominio/cualquier_directorio inmediatamente nos aparezca una ventana solicitando un nombre de usuario y una contraseña.
::[INTRO]::

Desde hace algún tiempo (como desde 1999) he venido estudiando estos asuntos de Ingeniería Inversa. Quisiera entrar a polemizar con cada uno de los que lee este post, sobre el buen o mal uso de la Ingeniería Inversa. La verdad, como programador siempre me han inquietado muchos asuntos sobre la ejecución del código que escribo. Me hago preguntas como las siguientes: ¿cómo harían para programar eso?, ¿cómo hago para que mi programa se comporte de cierta manera?, ¿cómo hago para mejorar la seguridad de una versión DEMO que entrego?. A todas estas y mas preguntas me he enfrentado al desarrollar programas; como sabrán, encontrar las respuestas adecuadas ha llevado y seguirá llevando tiempo. Pero por ahora les puedo adelantar, que el estudio de las técnicas de Ingeniería Inversa, el Lenguaje Ensamblador, las APIs de los sistemas operativos con los que trabajo (Linux y Windows), las técnicas de Overflow y demás asuntos relacionados con esos aspectos de bajo nivel que muchos no quieren ni mirar, me han llevado a encontrar las respuestas, mas o menos adecuadas, a las preguntas que me planteo.
::[INTRO]::

Describo en este mini-mini-howto, como cambiar el puerto seguro de la Web GUI disponible para la administración remota de nuestra maquina basade en IPCop. Para los que no sabemos, IPCop es un Firewall basado en Linux, se puede conseguir en http://www.ipcop.org.
IPCop dispone de una GUI (Graphical User Interface) para la administración remota del sistema. Esta GUI está hecha en perl con los módulos de CGI, se soporta sobre Apache como servidor Web para ofrecer todos sus servicios. Desde la LAN podemos ingresar a esta GUI haciendo una solicitud http desde nuestro browser dirigida al puerto 81, por ejemplo http://10.1.0.253:81 sería la manera correcta de solictar a la maquina 10.1.0.253, la cual tiene IPCop instalado, el servicio de la Web GUI. Cuando desde la LAN hacemos la solicitud http al puerto 81, IPCop hace una redirección, utilizando un código de estado 302 en el protocolo a otra localización. Lo realmente importante de lo anterior, es que cuando se hace esta redirección, el protocolo cambia a https y el puerto pasa del 81 al 445. Hasta aquí no hay problema, el problema es que desde afuera de la LAN, las solicitudes a la Web GUI de IPCop tienen que ir dirigidas exactamente al puerto 445 utilizando https.
En este mini-mini-howto vamos a cambiar el puerto seguro del servidor httpd, para que no escuche en el 445 sino en el 441.
::[ANTECEDENTES]::