«Un nuevo tutorial que muestra cómo configurar un servidor CentOS 5.2, que ofrezca todos los servicios necesarios para un ISP y alojamiento web: servidor web Apache (con SSL), servidor de correo Postfix con SMTP-AUTH y TLS, servidor DNS con BIND, servidor FTP con Proftpd, servidor MySQL, Dovecot POP3/IMAP, Quota, Firewall, etc. El tutorial está escrito para la versión de 32 bits de CentOS 5.2, pero debería poder aplicarse igualmente a la versión de 64 bits con muy pocos cambios.»
http://www.howtoforge.com/perfect-server-centos-5.2
martes, 12 de agosto de 2008
Actualizar el kernel a partir de paquetes RPM
¿Es conveniente actualizar el Kernel? Si. La utilidad de actualizar un Kernel consiste en contar con soporte para un mayor número de dispositivos de hardware, pero principalmente por los parches de seguridad y mejoras que la actualización incluya.
El método tradicional consiste en descargar el código fuente desde http://www.kernel.org y configurar las opciones deseadas, compilarlo e instalarlo uno mismo. Ciertamente esto permite un mayor control sobre las características deseadas, pero puede resultar un procedimiento algo complejo para un usuario novicio. Lo más sensato que puede hacer un usuario recién ingresado al mundo de GNU/Linux utilizando alguna distribución basada sobre Red Hat™ Linux, consiste en utilizar los paquetes pre-compilados.
Procedimientos para Fedora™ Core
Si usted utiliza Fedora™ Core 1, olvidese de preocupaciones (y del resto de este documento) puesto que puede limitarse a ejecutar un solo mandato que se hará cargo de actualizar el kernel si así se requiere (con todo lo que también sea necesario):
yum update
Acto seguido, reinicie sistema para poder utilizar el kernel recién instalado.
Procedimientos para otras distribuciones que utilizan RPM
Determinemos que versión del kernel se tiene instalado preguntándole al sistema con el siguiente mandato:
rpm -q kernel
Lo cual debe devolver algo como lo siguiente:
kernel-kernel-2.4.18-3
Diríjase con el explorador web de su preferencia al ftp de las distribución que posea y compare la versión del Kernel que encontrará en la carpeta de actualizaciones correspondiente a la versión que posea. Para las distribuciones basadas fielmente sobre Red Hat™ Linux, puede acceder a las siguientes direcciones:
ftp://updates.redhat.com/9/ o http://updates.redhat.com/9/, si posee alguna distribución basada sobre Red Hat Linux 9
Dentro de cada una encontrará un directorio i386, donde se encuentra la paquetería que puede instalarse en maquinas con cualquier microprocesador de arquitectura 80386, 80486, 80586 y 80686. Descargue los siguiente paquetes:
kernel-x.x.xx-xx.i386.rpm (si su equipo tiene microprocesador 80386 y 80486)
kernel-doc-x.x.xx-xx.i386.rpm
kernel-source-x.x.xx-xx.i386.rpm (opcional)
En el subdirectorio i586 encontrará dos paquetes, el paquete kernel-x.x.xx-xx.i586.rpm, optimizado para microprocesadores 80586, como AMD K5, K6, K6-II y K6-III y Pentium, Pentium MMX y Pentium Pro, y el paquete kernel-smp-x.x.xx-xx.i586.rpm, para maquinas que utilizan múltiples microprocesadores 80586. En el subdirectorio i686 encontrará dos paquetes, el paquete kernel-x.x.xx-xx.i686.rpm, optimizado para microprocesadores 80686, como los Celeron, Pentium II y Pentium III, y el paquete kernel-smp-x.x.xx-xx.i686.rpm, para maquinas que utilizan múltiples microprocesadores 80686.
Lo siguiente será crear un disquete de arranque con el kernel actual y que será de utilidad en caso de presentarse alguna complicación para poder arrancar el sistema. Éste puede generarse introduciendo un disquete, sin montarlo, en la unidad de 3œ pulgadas y ejecutando lo siguiente:
mkbootdisk --device /dev/fd0 [número de versión del kernel actual]
Suponiendo que se tiene instalado el kernel versión 2.4.20-8, incluido en Red Hat Linux 9, quedaría del siguiente modo:
/sbin/mkbootdisk 2.4.20-8 --device /dev/fd0
A continuación procederemos a probar dicho disquete, solo como una precaución. Déjelo insertado y reinicie el equipo.
Coloque todos los paquetes que descargó en el mismo directorio, y ejecute el siguiente mandato:
rpm -Fvh kernel-*.rpm
NOTA: No ponga en le mismo directorio aquellos que no correspondan a la arquitectura de su microprocesador o que puedan ser sustituidos por otros optimizados para la arquitectura de su microprocesador, es decir, por ejemplo, no se pongan kernel-2.4.20-28.9.i386.rpm y kernel-2.4.20-28.9.i586.rpm si se va a actualizar con el paquete kernel-2.4.20-28.9.i686.rpm, o recibirá errores de conflictos debido a paquetes iguales y no podrá instalar.
Gracias a que las distribuciones actuales utilizan Grub en lugar de Lilo, ya no es necesario editar fichero de configuración alguno ni ejecutar mandato alguno adicional.
Reinicie la máquina y compruebe que todo carga correctamente. Para mayor seguridad, ejecute el siguiente mandato inmediatamente después de reiniciar el sistema a fin de calcular las dependencias entre los módulos del nuevo kernel:
/sbin/depmod -a
Si todo funcionó correctamente, genere un disquete de arranque con el nuevo kernel para futuras emergencias, del mismo modo que lo hizo para el kernel anterior.
/sbin/mkbootdisk 2.4.20-28.9 --device /dev/fd0
Si se tenían módulos para dispositivos de hardware, como serían el módulo de kernel para tarjetas NVIDIA, o bien funciones adicionales, y estos fueron compilados con las cabeceras del kernel anterior, será necesario volver a compilar estos módulos a fin de hacerlos funcionar con el nuevo kernel. Asegúrese de que el enlace simbólico /usr/src/linux apunta realmente al directorio que contenga el código fuente del kernel actual, y verifique que el tipo de microprocesador y si hay multiprocesamiento simétrico están correctamente especificados en /usr/src/linux/.config -utilice make xconfig y será más sencillo- así como también el soporte para módulos experimentales de ser necesario.
Si necesita recompilar el kernel por alguna razón, el siguiente es el resumen de procedimientos:
cd /usr/src/linux/
make menuconfig
make dep
make clean
make bzImage
make install
make modules
make modules_install
Debe ejecutarse el siguiente mandato inmediatamente después de reiniciar el sistema a fin de calcular las dependencias entre los módulos.
/sbin/depmod -a
El método tradicional consiste en descargar el código fuente desde http://www.kernel.org y configurar las opciones deseadas, compilarlo e instalarlo uno mismo. Ciertamente esto permite un mayor control sobre las características deseadas, pero puede resultar un procedimiento algo complejo para un usuario novicio. Lo más sensato que puede hacer un usuario recién ingresado al mundo de GNU/Linux utilizando alguna distribución basada sobre Red Hat™ Linux, consiste en utilizar los paquetes pre-compilados.
Procedimientos para Fedora™ Core
Si usted utiliza Fedora™ Core 1, olvidese de preocupaciones (y del resto de este documento) puesto que puede limitarse a ejecutar un solo mandato que se hará cargo de actualizar el kernel si así se requiere (con todo lo que también sea necesario):
yum update
Acto seguido, reinicie sistema para poder utilizar el kernel recién instalado.
Procedimientos para otras distribuciones que utilizan RPM
Determinemos que versión del kernel se tiene instalado preguntándole al sistema con el siguiente mandato:
rpm -q kernel
Lo cual debe devolver algo como lo siguiente:
kernel-kernel-2.4.18-3
Diríjase con el explorador web de su preferencia al ftp de las distribución que posea y compare la versión del Kernel que encontrará en la carpeta de actualizaciones correspondiente a la versión que posea. Para las distribuciones basadas fielmente sobre Red Hat™ Linux, puede acceder a las siguientes direcciones:
ftp://updates.redhat.com/9/ o http://updates.redhat.com/9/, si posee alguna distribución basada sobre Red Hat Linux 9
Dentro de cada una encontrará un directorio i386, donde se encuentra la paquetería que puede instalarse en maquinas con cualquier microprocesador de arquitectura 80386, 80486, 80586 y 80686. Descargue los siguiente paquetes:
kernel-x.x.xx-xx.i386.rpm (si su equipo tiene microprocesador 80386 y 80486)
kernel-doc-x.x.xx-xx.i386.rpm
kernel-source-x.x.xx-xx.i386.rpm (opcional)
En el subdirectorio i586 encontrará dos paquetes, el paquete kernel-x.x.xx-xx.i586.rpm, optimizado para microprocesadores 80586, como AMD K5, K6, K6-II y K6-III y Pentium, Pentium MMX y Pentium Pro, y el paquete kernel-smp-x.x.xx-xx.i586.rpm, para maquinas que utilizan múltiples microprocesadores 80586. En el subdirectorio i686 encontrará dos paquetes, el paquete kernel-x.x.xx-xx.i686.rpm, optimizado para microprocesadores 80686, como los Celeron, Pentium II y Pentium III, y el paquete kernel-smp-x.x.xx-xx.i686.rpm, para maquinas que utilizan múltiples microprocesadores 80686.
Lo siguiente será crear un disquete de arranque con el kernel actual y que será de utilidad en caso de presentarse alguna complicación para poder arrancar el sistema. Éste puede generarse introduciendo un disquete, sin montarlo, en la unidad de 3œ pulgadas y ejecutando lo siguiente:
mkbootdisk --device /dev/fd0 [número de versión del kernel actual]
Suponiendo que se tiene instalado el kernel versión 2.4.20-8, incluido en Red Hat Linux 9, quedaría del siguiente modo:
/sbin/mkbootdisk 2.4.20-8 --device /dev/fd0
A continuación procederemos a probar dicho disquete, solo como una precaución. Déjelo insertado y reinicie el equipo.
Coloque todos los paquetes que descargó en el mismo directorio, y ejecute el siguiente mandato:
rpm -Fvh kernel-*.rpm
NOTA: No ponga en le mismo directorio aquellos que no correspondan a la arquitectura de su microprocesador o que puedan ser sustituidos por otros optimizados para la arquitectura de su microprocesador, es decir, por ejemplo, no se pongan kernel-2.4.20-28.9.i386.rpm y kernel-2.4.20-28.9.i586.rpm si se va a actualizar con el paquete kernel-2.4.20-28.9.i686.rpm, o recibirá errores de conflictos debido a paquetes iguales y no podrá instalar.
Gracias a que las distribuciones actuales utilizan Grub en lugar de Lilo, ya no es necesario editar fichero de configuración alguno ni ejecutar mandato alguno adicional.
Reinicie la máquina y compruebe que todo carga correctamente. Para mayor seguridad, ejecute el siguiente mandato inmediatamente después de reiniciar el sistema a fin de calcular las dependencias entre los módulos del nuevo kernel:
/sbin/depmod -a
Si todo funcionó correctamente, genere un disquete de arranque con el nuevo kernel para futuras emergencias, del mismo modo que lo hizo para el kernel anterior.
/sbin/mkbootdisk 2.4.20-28.9 --device /dev/fd0
Si se tenían módulos para dispositivos de hardware, como serían el módulo de kernel para tarjetas NVIDIA, o bien funciones adicionales, y estos fueron compilados con las cabeceras del kernel anterior, será necesario volver a compilar estos módulos a fin de hacerlos funcionar con el nuevo kernel. Asegúrese de que el enlace simbólico /usr/src/linux apunta realmente al directorio que contenga el código fuente del kernel actual, y verifique que el tipo de microprocesador y si hay multiprocesamiento simétrico están correctamente especificados en /usr/src/linux/.config -utilice make xconfig y será más sencillo- así como también el soporte para módulos experimentales de ser necesario.
Si necesita recompilar el kernel por alguna razón, el siguiente es el resumen de procedimientos:
cd /usr/src/linux/
make menuconfig
make dep
make clean
make bzImage
make install
make modules
make modules_install
Debe ejecutarse el siguiente mandato inmediatamente después de reiniciar el sistema a fin de calcular las dependencias entre los módulos.
/sbin/depmod -a
Actualizacion, Instalacion y Desinstalacion de software Linux
Una vez que ya ha experimentado con algunos de los mandatos básicos, se encontrará ahora con una pregunta: ¿Cómo actualizo, instalo o desinstalo software? Existen varios métodos que dependerán del formato utilizado para empaquetar los programas. Este documento le proporcionará la descripción de los posibles métodos y algunos ejemplos. Por favor siga el procedimiento al pie de la letra.
La parte teórica.
Antes de continuar, es indispensable se conozca primero el uso y el porque de cada método existente para el manejo del software. De esto se dependerá en adelante para mantener un saludable estado de cualquier sistema GNU/Linux®. Indistintamente del método, todos se deberá de realizar desde la cuenta de root, así que proceda con cuidado.
Manejo de paquetes a partir de archivos RPM®
El formato RPM® es el más utilizado en la actualidad. Tiene como ventaja principal el encargarse de verificar las posibles dependencias o requisitos para la instalación o actualización de un paquete en particular, así como también el verificar si el paquete que se procederá a desinstalar es requerido por otros paquetes presentes en el sistema.
Analizaremos entonces el uso del mandato rpm. Existen dos aplicaciones en el entorno gráfico que utilizan rpm en el trasfondo y que son de muy fácil utilización, son gnorpm y kpackage. Sin embargo es importante que el usuario novicio se familiarice con este mandato para poder entender el funcionamiento de las mencionadas aplicaciones en el entorno gráfico.
Sintaxis
rpm -[opciones] paquete.rpmNos limitaremos a abordar solo las opciones más comúnes que un nuevo usuario de Linux® podría necesitar. Si desea ver una descripción completa de las posibles opciones del mandato rpm, consulte el manual escribiendo man rpm en cualquier terminal o consola.
Instalación binarios contenidos en paquetes con formato RPM®.
Los paquetes de este tipo son programas previamente compilados, almacenados y listos para ser instalados en el sistema. Estos paquetes pueden tener las extensiones .i386.rpm para PC compatible con al menos un microprocesador 80386, es decir, cualquier PC de arquitectura Intel® o compatible, .i486.rpm para PC compatible un microprocesador 80486, .i586.rpm para PC compatible con microprocesador 80586, .i686.rpm para PC compatible con microprocesador 80686, .ppc.rpm para Machintosh® PowerPC o .noarch.rpm que puede utilizarse en cualquier arquitectura.
En la práctica, no se preocupe por encontrar paquetes i686 para su PC con microprocesador Intel Pentium III, puede instalar con total seguridad los paquetes para i386. Los paquetes noarch generalmente contiene archivos de texto -guiones para diversas funciones, archivos de configuración o documentación-, imágenes, sonidos, etc., es decir, archivos que trabajan indistintamente en uno u otro sistema.
La sintaxis que se sugiere utilizar en la mayoría de los casos para instalar o actualizar paquetería es la siguiente:
rpm -Uvh paquete.i386.rpmEl utilizar la opción U, que significa Update, a fin de conseguir un proceso limpio, hace que primero se consulte la base de datos de la paquetería instalada, procediendo a desinstalar a continuación la versión anterior e instalando la nueva. Aunque también puede utilizarse la opción i, que significa install, esta no continuará el proceso si existiese en el sistema una versión anterior de dicho paquete.
Desinstalación binarios contenidos en paquetes con formato RPM®.
rpm -e paqueteNo requiere especificar el número de versión ni la extensión ya que consulta directamente la base de datos de la paquetería instalada en le sistema y procederá a desinstalar el paquete que lleve dicho nombre.
Instalación a partir de código fuente contenido en paquetes con formato RPM®.
Este procedimiento se aplica a los paquetes denominados SRPM, sobre los cuales seguramente ha leído en los foros y grupos d discusión, y requiere que se encuentren instalados en el sistema los paquetes de desarrollo -los paquetes contenidos en el CDROM de instalación que llevan "-devel-" en el nombre-, ya que el procedimiento implica que se realizará la compilación de programas.
La ventaja que tiene la construcción e instalación paquetería a partir de archivos SRPM es que los paquetes resultantes quedan compilados de forma especial para el sistema Linux® que tengamos instalado. Es de particular ayuda cuando se actualiza, por citar un ejemplo, de LinuxPPP® 5.x a LinuxPPP® 6.x y el usuario se topa con que alguna de sus aplicaciones favoritas simplemente ya no funcionan. Esto se debe a que la diferencia entre las versiones de las bibliotecas compartidas entre una y otra versión de LinuxPPP puede ser demasiada. Las distribuciones basadas sobre Red Hat™ Linux 5.x utilizan, entre otras cosas, libc5, en tanto que las versiones basadas sobre Red Hat™ 6.x hacen uso de Glibc-2.1.x y las versiones basadas sobre Red Hat™ 7.x hacen uso de Glibc-2.2.x.
Estos paquetes SRPM tienen la extensión .src.rpm y se procede sobre estos del siguiente modo:
rpmbuild --rebuild --clean paquete.src.rpmEsta última línea de mandato coloca un paquete comprimido, normalmente un archivo con extensión .tar.gz o tar.bz2, en /usr/src/redhat/SOURCES y un archivo, conocido como spec, con las especificaciones del paquete en /usr/src/redhat/SPECS. A continuación se descomprime el archivo .tar.gz o tar.bz2 y se inicia la compilación y construcción del paquete RPM® con las especificaciones del spec.
Si al terminar el proceso en la última línea se obtiene + exit 0, solo restará instalar o actualizar con el paquete RPM® que ahora encontraremos, dependiendo de la arquitectura para la que se compiló, en alguno de los subdirectorios de /usr/src/redhat/RPMS.
rpm -Uvh /usr/src/redhat/RPMS/i386/paquete.i386.rpmConfirmación de la existencia de paquetería en particular en el sistema.
En ocasiones es posible que se encuentre en una situación como esta: usted encuentra en algún sitio de Internet un paquete RPM® del cual se hablan maravillas en la descripción, pero desconoce si ya lo tendrá instalado, o si ya tiene una versión más reciente; podría averiguarlo descargando dicho paquete, que quizá tenga varios Mega-bytes en tamaño, utilizando una lenta conexión de modem y probando con la línea de mandato rpm -Uvh. Si resultó un paquete más reciente que el que usted tenía, habrán valido la pena los 10-15 minutos invertidos en descargar dicho paquete, pero si ya lo tenía instalado o bien se trataba de una versión anterior, usted desearía haber sabido que podía utilizar la siguiente línea de mandato:
rpm -q nombre_del_paquete_sin_número_de_versiónLa correspondiente salida de esto nos dirá si el paquete se encuentra o no instalado y el número de versión.
Si nos interesa examinar la información sobre algún paquete instalado en el sistema, utilizamos la siguiente línea de mandato:
rpm -qi nombre_del_paquete_sin_número_de_versiónLo anterior devuelve los detalles informativos respecto al paquete instalado.
Si queremos examinar dicha información pero en un paquete no instalado en el sistema, solo hace falta añadir p, que implica que nos referiremos a un paquete, en las opciones del mandato del modo siguiente:
rpm -qpi --clean cualquier_paquete_que_haya_descargado.i386.rpmVerificación de firmas de paquetes RPM®.
Por cuestiones de seguridad, si usted descarga un paquete RPM® desde un sitio Web o servidor FTP distinto al oficial de la distribución o conjunto de paquetes que utilice, lo más saludable será verificar dicho paquete. JAMÁS descargue e instale paquetes de binarios desde sitios Web dedicados a actividades ilegales o de dudosa reputación.
Por si acaso, utilice la siguiente línea de mandato para verificar las firmas incluidas en paquetes antes de proceder a instalarlos:
rpm -Kv paquete.i386.rpmEsto debe darle la siguiente salida, donde las x corresponden a la firma PGP de la persona que construyó el paquete:
paquete.i386.rpm:
MD5 sum OK: xxxxxxxxxxxxxxxxxxxxxCompare la firma PGP con la del empaquetador, misma que debe corresponder con la que este proporcione en el sitio Web desde donde descargue dicho paquete.
Instalación de paquetes a partir de paquetes .tar.gz o .tar.bz2.
Este el el método universal para todas las distribuciones de GNU/Linux® ya que funciona tanto en distribuciones basadas sobre Red Hat, como Debian, Stampede o Slackware. Debido a que no se guarda un registro sobre lo que se tiene instalado y lo que no, conviene, en le caso de distribuciones basadas sobre Red Hat™ Linux, dejar las carpetas resultantes con el código fuente en /usr/src/redhat/BUILD para tener una referencia y evitar romper las posibles dependencias entre los distintos paquetes.
La mayoría de estos paquetes, denominados tarballs, vienen con extensión .tar.gz o tar.bz2. Lo primero será copiarlos en la carpeta /usr/src/redhat/SOURCES y lo siguiente consiste en descomprimir estos con la siguiente línea de mandato:
tar -zxvf /usr/src/redhat/SOURCES/paquete.tar.gz /usr/src/redhat/BUILD/Después acceda al interior de la carpeta resultante:
cd /usr/src/redhat/BUILD/paqueteEs necesario que lea la documentación que acompaña a dicho paquete y seguir las instrucciones proporcionadas por el autor. Por lo general son necesarios al menos tres pasos:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
make
make install
make cleanAlgunos paquetes de binarios propietarios, como OpenOffice.org, incluyen documentación y un instructivo que detalla la instalación. OpenOffice.org requiere se ejecute el binario setup, con la opción /net si va ser utilizado por varios usuarios, contenido en la sub-carpeta bin.
cd /usr/src/redhat/BUILD/openoffice
./setup /netEn la mayoría de los casos, como ocurre con los programas con licencia GPL que se distribuyen como códigos fuentes, necesitará ejecutar algunos mandatos como se muestra a continuación:
Compilación desde código fuente.
./configure
Este prepara el Makefile y configura las opciones de compilación, mismas que en algunos casos pueden resultar demasiado complejas para un usuario novicio. Además de verifica si el sistema posee las bibliotecas de desarrollo necesarias para la compilación.
make
Este es el que realiza la compilación del código fuente. El procesos puede durar varios minutos.
make install
Este se encarga de realizar la instalación del los binarios y módulos compilados en los lugares correctos.
make clean
Opcionalmente podemos utilizar este mandato para limpiar los remanentes que se originaron por la compilación a fin de recuperar espacio en el disco duro.
Si por alguna razón necesita desinstalar el programa resultante, puede utilizar make uninstall.
En el mejor de los casos, si el tarball contiene un archivo spec, puede construirse un paquete RPM® de modo muy similar a la compilación e instalación desde paquetes SRPMS.
Solo requiere ejecutar la siguiente línea de mandato:
rpm -tb --clean paquete.tar.gzY, si obtuvimos en la última línea del proceso un + exit 0, finalmente podremos disponer de el paquete resultante:
rpm -Uvh /usr/src/redhat/RPMS/i386/paquete.i386.rpmEjercicios.
Antes de empezar, es necesario, si no lo ha hecho, instalar los paquetes de bibliotecas de desarrollo incluidas en el CDROM de instalación de la distribución que posea. Puede utilizar rpm -Uvh *-devel-*.
Instalación y desinstalación de un paquete RPM®
Instale firestarter-x.x.x-x.i586.rpm con la siguiente línea mandato:
rpm -Uvh firestarter-*.i586.rpmEjecute el programa que acaba de instalar ejecutando firestarter
Cierre el programa ejecutemos el mandato para verificar que versión tenemos instalada: y observe la salida
rpm -q firestarterProceda ahora a desinstalar el programa con la siguiente línea de mandato:
rpm -e firestarter
Compilación e instalación desde un SRPM.
Ejecute el siguiente mandato:
rpmbuild --rebuild --clean firestarter-*.src.rpmEspere unos minutos, y si recibe en la última línea una salida +exit 0, cambie al directorio conde quedó el paquete RPM® de binarios:
cd /usr/src/redhat/RPMS/i386 ; lsInstale el RPM® resultante con la siguiente línea de mandato:
rpm -Uvh firestarter-*.i386.rpmEjecute el programa que acaba de instalar ejecutando firestarter
Cierre el programa ejecutemos el mandato para verificar que versión tenemos instalada: y observe la salida
rpm -q firestarterProceda ahora a desinstalar el programa con la siguiente línea de mandato:
rpm -e firestarter
Compilación e instalación desde código fuente -tarball-.
Abra una terminal o consola.
Instale este paquete, que contiene un código fuente, con la siguiente línea de mandato.
rpm -Uvh firestarter-*.src.rpmRevise el contenido de los siguientes directorios, ya que en estos encontrará un par de archivos nuevos:
cd /usr/src/redhat/SPECS ; lsEn este encontrará un archivo llamado firestarter.spec
cd /usr/src/redhat/SOURCES ; lsEn este otro encontrará firestarter-0.8.2.tar.gz
Descomprima firestarter-0.8.2.tar.gz utilizando la siguiente línea de mandato:
tar -zxvf /usr/src/redhat/SOURCES/firestarter-0.8.2.tar.gz /usr/src/redhat/BUILDComo resultado, ahora tendremos una carpeta firestarter-0.8.2.
Cambie al directorio /usr/src/redhat/BUILD/firestarter-0.8.2:
cd /usr/src/redhat/BUILD/firestarter-0.8.2Ejecute el siguiente mandato y observe los mensajes que aparecerán en pantalla:
./configureEjecute el siguiente mandato para iniciar la compilación, espere algunos minutos para que completen todos los procesos y observe los mensajes que aparecerán en pantalla, sobretodo asegurándose que la última línea se lea + exit 0:
makeEjecute el siguiente mandato a fin de instalar el programa que acaba de compilar:
make installEjecute el siguiente mandato para comprobar que ha concluído exitosamente la primera parte del ejercicio,, invocando a firestarter, un programa de correo electrónico:
firestarterProceda a desinstalar firestarter:
make uninstallFinalmente, a fin de recuperar algo de espacio en disco duro, procederemos a limpiar los módulos y binarios creados dentro de /usr/src/redhat/BUILD/firestarter-0.8.2
make clean
La parte teórica.
Antes de continuar, es indispensable se conozca primero el uso y el porque de cada método existente para el manejo del software. De esto se dependerá en adelante para mantener un saludable estado de cualquier sistema GNU/Linux®. Indistintamente del método, todos se deberá de realizar desde la cuenta de root, así que proceda con cuidado.
Manejo de paquetes a partir de archivos RPM®
El formato RPM® es el más utilizado en la actualidad. Tiene como ventaja principal el encargarse de verificar las posibles dependencias o requisitos para la instalación o actualización de un paquete en particular, así como también el verificar si el paquete que se procederá a desinstalar es requerido por otros paquetes presentes en el sistema.
Analizaremos entonces el uso del mandato rpm. Existen dos aplicaciones en el entorno gráfico que utilizan rpm en el trasfondo y que son de muy fácil utilización, son gnorpm y kpackage. Sin embargo es importante que el usuario novicio se familiarice con este mandato para poder entender el funcionamiento de las mencionadas aplicaciones en el entorno gráfico.
Sintaxis
rpm -[opciones] paquete.rpmNos limitaremos a abordar solo las opciones más comúnes que un nuevo usuario de Linux® podría necesitar. Si desea ver una descripción completa de las posibles opciones del mandato rpm, consulte el manual escribiendo man rpm en cualquier terminal o consola.
Instalación binarios contenidos en paquetes con formato RPM®.
Los paquetes de este tipo son programas previamente compilados, almacenados y listos para ser instalados en el sistema. Estos paquetes pueden tener las extensiones .i386.rpm para PC compatible con al menos un microprocesador 80386, es decir, cualquier PC de arquitectura Intel® o compatible, .i486.rpm para PC compatible un microprocesador 80486, .i586.rpm para PC compatible con microprocesador 80586, .i686.rpm para PC compatible con microprocesador 80686, .ppc.rpm para Machintosh® PowerPC o .noarch.rpm que puede utilizarse en cualquier arquitectura.
En la práctica, no se preocupe por encontrar paquetes i686 para su PC con microprocesador Intel Pentium III, puede instalar con total seguridad los paquetes para i386. Los paquetes noarch generalmente contiene archivos de texto -guiones para diversas funciones, archivos de configuración o documentación-, imágenes, sonidos, etc., es decir, archivos que trabajan indistintamente en uno u otro sistema.
La sintaxis que se sugiere utilizar en la mayoría de los casos para instalar o actualizar paquetería es la siguiente:
rpm -Uvh paquete.i386.rpmEl utilizar la opción U, que significa Update, a fin de conseguir un proceso limpio, hace que primero se consulte la base de datos de la paquetería instalada, procediendo a desinstalar a continuación la versión anterior e instalando la nueva. Aunque también puede utilizarse la opción i, que significa install, esta no continuará el proceso si existiese en el sistema una versión anterior de dicho paquete.
Desinstalación binarios contenidos en paquetes con formato RPM®.
rpm -e paqueteNo requiere especificar el número de versión ni la extensión ya que consulta directamente la base de datos de la paquetería instalada en le sistema y procederá a desinstalar el paquete que lleve dicho nombre.
Instalación a partir de código fuente contenido en paquetes con formato RPM®.
Este procedimiento se aplica a los paquetes denominados SRPM, sobre los cuales seguramente ha leído en los foros y grupos d discusión, y requiere que se encuentren instalados en el sistema los paquetes de desarrollo -los paquetes contenidos en el CDROM de instalación que llevan "-devel-" en el nombre-, ya que el procedimiento implica que se realizará la compilación de programas.
La ventaja que tiene la construcción e instalación paquetería a partir de archivos SRPM es que los paquetes resultantes quedan compilados de forma especial para el sistema Linux® que tengamos instalado. Es de particular ayuda cuando se actualiza, por citar un ejemplo, de LinuxPPP® 5.x a LinuxPPP® 6.x y el usuario se topa con que alguna de sus aplicaciones favoritas simplemente ya no funcionan. Esto se debe a que la diferencia entre las versiones de las bibliotecas compartidas entre una y otra versión de LinuxPPP puede ser demasiada. Las distribuciones basadas sobre Red Hat™ Linux 5.x utilizan, entre otras cosas, libc5, en tanto que las versiones basadas sobre Red Hat™ 6.x hacen uso de Glibc-2.1.x y las versiones basadas sobre Red Hat™ 7.x hacen uso de Glibc-2.2.x.
Estos paquetes SRPM tienen la extensión .src.rpm y se procede sobre estos del siguiente modo:
rpmbuild --rebuild --clean paquete.src.rpmEsta última línea de mandato coloca un paquete comprimido, normalmente un archivo con extensión .tar.gz o tar.bz2, en /usr/src/redhat/SOURCES y un archivo, conocido como spec, con las especificaciones del paquete en /usr/src/redhat/SPECS. A continuación se descomprime el archivo .tar.gz o tar.bz2 y se inicia la compilación y construcción del paquete RPM® con las especificaciones del spec.
Si al terminar el proceso en la última línea se obtiene + exit 0, solo restará instalar o actualizar con el paquete RPM® que ahora encontraremos, dependiendo de la arquitectura para la que se compiló, en alguno de los subdirectorios de /usr/src/redhat/RPMS.
rpm -Uvh /usr/src/redhat/RPMS/i386/paquete.i386.rpmConfirmación de la existencia de paquetería en particular en el sistema.
En ocasiones es posible que se encuentre en una situación como esta: usted encuentra en algún sitio de Internet un paquete RPM® del cual se hablan maravillas en la descripción, pero desconoce si ya lo tendrá instalado, o si ya tiene una versión más reciente; podría averiguarlo descargando dicho paquete, que quizá tenga varios Mega-bytes en tamaño, utilizando una lenta conexión de modem y probando con la línea de mandato rpm -Uvh. Si resultó un paquete más reciente que el que usted tenía, habrán valido la pena los 10-15 minutos invertidos en descargar dicho paquete, pero si ya lo tenía instalado o bien se trataba de una versión anterior, usted desearía haber sabido que podía utilizar la siguiente línea de mandato:
rpm -q nombre_del_paquete_sin_número_de_versiónLa correspondiente salida de esto nos dirá si el paquete se encuentra o no instalado y el número de versión.
Si nos interesa examinar la información sobre algún paquete instalado en el sistema, utilizamos la siguiente línea de mandato:
rpm -qi nombre_del_paquete_sin_número_de_versiónLo anterior devuelve los detalles informativos respecto al paquete instalado.
Si queremos examinar dicha información pero en un paquete no instalado en el sistema, solo hace falta añadir p, que implica que nos referiremos a un paquete, en las opciones del mandato del modo siguiente:
rpm -qpi --clean cualquier_paquete_que_haya_descargado.i386.rpmVerificación de firmas de paquetes RPM®.
Por cuestiones de seguridad, si usted descarga un paquete RPM® desde un sitio Web o servidor FTP distinto al oficial de la distribución o conjunto de paquetes que utilice, lo más saludable será verificar dicho paquete. JAMÁS descargue e instale paquetes de binarios desde sitios Web dedicados a actividades ilegales o de dudosa reputación.
Por si acaso, utilice la siguiente línea de mandato para verificar las firmas incluidas en paquetes antes de proceder a instalarlos:
rpm -Kv paquete.i386.rpmEsto debe darle la siguiente salida, donde las x corresponden a la firma PGP de la persona que construyó el paquete:
paquete.i386.rpm:
MD5 sum OK: xxxxxxxxxxxxxxxxxxxxxCompare la firma PGP con la del empaquetador, misma que debe corresponder con la que este proporcione en el sitio Web desde donde descargue dicho paquete.
Instalación de paquetes a partir de paquetes .tar.gz o .tar.bz2.
Este el el método universal para todas las distribuciones de GNU/Linux® ya que funciona tanto en distribuciones basadas sobre Red Hat, como Debian, Stampede o Slackware. Debido a que no se guarda un registro sobre lo que se tiene instalado y lo que no, conviene, en le caso de distribuciones basadas sobre Red Hat™ Linux, dejar las carpetas resultantes con el código fuente en /usr/src/redhat/BUILD para tener una referencia y evitar romper las posibles dependencias entre los distintos paquetes.
La mayoría de estos paquetes, denominados tarballs, vienen con extensión .tar.gz o tar.bz2. Lo primero será copiarlos en la carpeta /usr/src/redhat/SOURCES y lo siguiente consiste en descomprimir estos con la siguiente línea de mandato:
tar -zxvf /usr/src/redhat/SOURCES/paquete.tar.gz /usr/src/redhat/BUILD/Después acceda al interior de la carpeta resultante:
cd /usr/src/redhat/BUILD/paqueteEs necesario que lea la documentación que acompaña a dicho paquete y seguir las instrucciones proporcionadas por el autor. Por lo general son necesarios al menos tres pasos:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
make
make install
make cleanAlgunos paquetes de binarios propietarios, como OpenOffice.org, incluyen documentación y un instructivo que detalla la instalación. OpenOffice.org requiere se ejecute el binario setup, con la opción /net si va ser utilizado por varios usuarios, contenido en la sub-carpeta bin.
cd /usr/src/redhat/BUILD/openoffice
./setup /netEn la mayoría de los casos, como ocurre con los programas con licencia GPL que se distribuyen como códigos fuentes, necesitará ejecutar algunos mandatos como se muestra a continuación:
Compilación desde código fuente.
./configure
Este prepara el Makefile y configura las opciones de compilación, mismas que en algunos casos pueden resultar demasiado complejas para un usuario novicio. Además de verifica si el sistema posee las bibliotecas de desarrollo necesarias para la compilación.
make
Este es el que realiza la compilación del código fuente. El procesos puede durar varios minutos.
make install
Este se encarga de realizar la instalación del los binarios y módulos compilados en los lugares correctos.
make clean
Opcionalmente podemos utilizar este mandato para limpiar los remanentes que se originaron por la compilación a fin de recuperar espacio en el disco duro.
Si por alguna razón necesita desinstalar el programa resultante, puede utilizar make uninstall.
En el mejor de los casos, si el tarball contiene un archivo spec, puede construirse un paquete RPM® de modo muy similar a la compilación e instalación desde paquetes SRPMS.
Solo requiere ejecutar la siguiente línea de mandato:
rpm -tb --clean paquete.tar.gzY, si obtuvimos en la última línea del proceso un + exit 0, finalmente podremos disponer de el paquete resultante:
rpm -Uvh /usr/src/redhat/RPMS/i386/paquete.i386.rpmEjercicios.
Antes de empezar, es necesario, si no lo ha hecho, instalar los paquetes de bibliotecas de desarrollo incluidas en el CDROM de instalación de la distribución que posea. Puede utilizar rpm -Uvh *-devel-*.
Instalación y desinstalación de un paquete RPM®
Instale firestarter-x.x.x-x.i586.rpm con la siguiente línea mandato:
rpm -Uvh firestarter-*.i586.rpmEjecute el programa que acaba de instalar ejecutando firestarter
Cierre el programa ejecutemos el mandato para verificar que versión tenemos instalada: y observe la salida
rpm -q firestarterProceda ahora a desinstalar el programa con la siguiente línea de mandato:
rpm -e firestarter
Compilación e instalación desde un SRPM.
Ejecute el siguiente mandato:
rpmbuild --rebuild --clean firestarter-*.src.rpmEspere unos minutos, y si recibe en la última línea una salida +exit 0, cambie al directorio conde quedó el paquete RPM® de binarios:
cd /usr/src/redhat/RPMS/i386 ; lsInstale el RPM® resultante con la siguiente línea de mandato:
rpm -Uvh firestarter-*.i386.rpmEjecute el programa que acaba de instalar ejecutando firestarter
Cierre el programa ejecutemos el mandato para verificar que versión tenemos instalada: y observe la salida
rpm -q firestarterProceda ahora a desinstalar el programa con la siguiente línea de mandato:
rpm -e firestarter
Compilación e instalación desde código fuente -tarball-.
Abra una terminal o consola.
Instale este paquete, que contiene un código fuente, con la siguiente línea de mandato.
rpm -Uvh firestarter-*.src.rpmRevise el contenido de los siguientes directorios, ya que en estos encontrará un par de archivos nuevos:
cd /usr/src/redhat/SPECS ; lsEn este encontrará un archivo llamado firestarter.spec
cd /usr/src/redhat/SOURCES ; lsEn este otro encontrará firestarter-0.8.2.tar.gz
Descomprima firestarter-0.8.2.tar.gz utilizando la siguiente línea de mandato:
tar -zxvf /usr/src/redhat/SOURCES/firestarter-0.8.2.tar.gz /usr/src/redhat/BUILDComo resultado, ahora tendremos una carpeta firestarter-0.8.2.
Cambie al directorio /usr/src/redhat/BUILD/firestarter-0.8.2:
cd /usr/src/redhat/BUILD/firestarter-0.8.2Ejecute el siguiente mandato y observe los mensajes que aparecerán en pantalla:
./configureEjecute el siguiente mandato para iniciar la compilación, espere algunos minutos para que completen todos los procesos y observe los mensajes que aparecerán en pantalla, sobretodo asegurándose que la última línea se lea + exit 0:
makeEjecute el siguiente mandato a fin de instalar el programa que acaba de compilar:
make installEjecute el siguiente mandato para comprobar que ha concluído exitosamente la primera parte del ejercicio,, invocando a firestarter, un programa de correo electrónico:
firestarterProceda a desinstalar firestarter:
make uninstallFinalmente, a fin de recuperar algo de espacio en disco duro, procederemos a limpiar los módulos y binarios creados dentro de /usr/src/redhat/BUILD/firestarter-0.8.2
make clean
Configurando valores por defecto para el alta de cuentas.
Procedimientos.
Como root, edite /etc/default/useradd. Encontrará el siguiente contenido:
# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
Puede cambiar lo valores que considere convenientes, como por ejemplo el intérprete de mandatos a utilizar para las nuevas cuentas que sean creadas en adelante. De modo predefinido el sistema asigna /bin/bash (BASH o Bourne Again Shell) como intérprete de mandatos, sin embargo lo cierto es que si el sistema se utilizará como servidor, lo más conveniente es que se asigne de modo predefinido /sbin/nologin el cual muestra un mensaje respecto a que la cuenta no está disponible y da salida, utilizándose regularmente como intérprete de mandatos de reemplazo para cuentas que han sido deshabilitadas o bien que no tiene porque acceder con intérprete de mandatos al sistema. Cambie SHELL=/bin/bash por SHELL=/sbin/nologin.
# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/sbin/nologin
SKEL=/etc/skel
En adelante todo nuevo usuario que sea dado de alta en el sistema con el mandato useradd sin parámetro alguno, de modo predefinido no podrá acceder al sistema a través de shell, es decir acceso en terminal local o remotamente. Los usuarios con estas características podrán, sin embargo, utilizar cuentas de correo o Samba sin problema alguno.
De modo predefinido las cuentas de usuario del sistema utilizarán como molde al directorio /etc/skel para crear el directorio de inicio de todos los usuarios del sistema. Regularmente, y como mínimo, /etc/skel incluye lo siguiente:
.bash_logout .bash_profile .bashrc .gtkrc
Si, por ejemplo, se desea que cada cuenta de usuario incluya un subdirectorio para carpetas de correo y suscripción a éstas a través del servicio de IMAP, se debe realizar el siguiente procedimiento:
mkdir /etc/skel/mail/touch /etc/skel/mail/Borradorestouch /etc/skel/mail/Enviadostouch /etc/skel/mail/Papelera
Y finalmente generar con el editor de texto el fichero /etc/skel/.mailboxlist que sirve para guardar las suscripciones de carpetas de correo que serán utilizadas por el servicio de IMAP, utilizando el siguiente contenido:
mail/Borradoresmail/Enviadosmail/Papelera
Adicionalmente puede contribuir a transparentar la migración de escritorios de GNOME 1.x, 2.0 y 2.2 hacia versiones posteriores predefiniendo se genere el directorio ~/Desktop/ con un enlace simbólico apuntando hacia éste y el cual se denominará ~/.gnome-desktop/
cd /etc/skel/mkdir Desktopln -s Desktop .gnome-desktop
Como root, edite /etc/default/useradd. Encontrará el siguiente contenido:
# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
Puede cambiar lo valores que considere convenientes, como por ejemplo el intérprete de mandatos a utilizar para las nuevas cuentas que sean creadas en adelante. De modo predefinido el sistema asigna /bin/bash (BASH o Bourne Again Shell) como intérprete de mandatos, sin embargo lo cierto es que si el sistema se utilizará como servidor, lo más conveniente es que se asigne de modo predefinido /sbin/nologin el cual muestra un mensaje respecto a que la cuenta no está disponible y da salida, utilizándose regularmente como intérprete de mandatos de reemplazo para cuentas que han sido deshabilitadas o bien que no tiene porque acceder con intérprete de mandatos al sistema. Cambie SHELL=/bin/bash por SHELL=/sbin/nologin.
# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/sbin/nologin
SKEL=/etc/skel
En adelante todo nuevo usuario que sea dado de alta en el sistema con el mandato useradd sin parámetro alguno, de modo predefinido no podrá acceder al sistema a través de shell, es decir acceso en terminal local o remotamente. Los usuarios con estas características podrán, sin embargo, utilizar cuentas de correo o Samba sin problema alguno.
De modo predefinido las cuentas de usuario del sistema utilizarán como molde al directorio /etc/skel para crear el directorio de inicio de todos los usuarios del sistema. Regularmente, y como mínimo, /etc/skel incluye lo siguiente:
.bash_logout .bash_profile .bashrc .gtkrc
Si, por ejemplo, se desea que cada cuenta de usuario incluya un subdirectorio para carpetas de correo y suscripción a éstas a través del servicio de IMAP, se debe realizar el siguiente procedimiento:
mkdir /etc/skel/mail/touch /etc/skel/mail/Borradorestouch /etc/skel/mail/Enviadostouch /etc/skel/mail/Papelera
Y finalmente generar con el editor de texto el fichero /etc/skel/.mailboxlist que sirve para guardar las suscripciones de carpetas de correo que serán utilizadas por el servicio de IMAP, utilizando el siguiente contenido:
mail/Borradoresmail/Enviadosmail/Papelera
Adicionalmente puede contribuir a transparentar la migración de escritorios de GNOME 1.x, 2.0 y 2.2 hacia versiones posteriores predefiniendo se genere el directorio ~/Desktop/ con un enlace simbólico apuntando hacia éste y el cual se denominará ~/.gnome-desktop/
cd /etc/skel/mkdir Desktopln -s Desktop .gnome-desktop
Mandato Chattr
El mandato chattr se utiliza para cambiar los atributos de los sistemas de ficheros ext2 y ext3. Desde cierto punto de vista, es análogo al mandato chmod, pero con diferente sintaxis y opciones. Utilizado adecuadamente, dificulta las acciones en el sistema de ficheros por parte de un intruso que haya logrado suficientes privilegios en un sistema.
En la mayoría de los casos, cuando un intruso consigue suficientes privilegios en un sistema, lo primero que hará será eliminar los registros de sus actividades modificando estructuras de los ficheros de bitácoras del sistema y otros componentes. Utilizar el mandato chattr ciertamente no es obstáculo para un usuario experto, pero, afortunadamente, la gran mayoría de los intrusos potenciales no suelen ser expertos en GNU/Linux o Unix, dependiendo enormemente de diversos programas o guiones (los denominados rootkits y zappers) para eliminar aquello que permita descubrir sus actividades.
Utilizar el mandato chattr, incluido en el paquete e2fsprogs, que se instala de forma predeterminada en todas las distribuciones de GNU/Linux por tratarse de un componente esencial, hace más difícil borrar o alterar bitácoras, ficheros de configuración y componentes del sistema. Theodore Ts'o es el desarrollador y quien se encarga de mantener e2fsprogs, mismo que se distribuye bajo los términos de la licencia GNU/GPL, e incluye otras herramientas como e2fsck, e2label, fsck.ext2, fsck.ext3, mkfs.ext2, mkfs.ext3, tune2fs y dumpe2fs, entre otras.
URL: http://e2fsprogs.sourceforge.net/
Opciones.
-R Cambia recursivamente los atributos de directorios y sus contenidos. Los enlaces simbólicos que se encuentren, son ignorado
-V Salida de charttr más descriptiva, mostrando además la versión del programa.
-v Ver el número de versión del programa.
Operadores.
+ Hace que se añadan los atributos especificados a los atributos existentes de un fichero.
- Hace que se eliminen los atributos especificados de los atributos existentes de un fichero
= Hace que solamente haya los atributos especificados.
Atributos.
A Establece que la fecha del último acceso (atime) no se modifica.
a Establece que el fichero solo se puede abrir en modo de adjuntar para escritura.
c Establece que el fichero es comprimido automáticamente en el disco por el núcleo del sistema operativo. Al realizar lectura de este fichero, se descomprimen los datos. La escritura de dicho fichero comprime los datos antes de almacenarlos en el disco.
D Cuando se trata de un directorio, establece que los datos se escriben de forma sincrónica en el disco. Es decir, los datos se escriben inmediatamente en lugar de esperar la operación correspondiente del sistema operativo. Es equivalente a la opción dirsync del mandato mount, pero aplicada a un subconjunto de ficheros.
d Establece que el fichero no sea candidato para respaldo al utilizar la herramienta dump.
i Establece que el fichero será inmutable. Es decir, no puede ser eliminado, ni renombrado, no se pueden apuntar enlaces simbólicos, ni escribir datos en el fichero.
j En los sistemas de ficheros ext3, cuando se montan con las opciones data=ordered o data=writeback, se establece que el fichero será escrito en el registro por diario (Journal). Si el sistema de ficheros se monta con la opción data=journal (opción predeterminada), todo el sistema de ficheros se escribe en el registro por diario y por lo tanto el atributo no tiene efecto.
s Cuando un fichero tiene este atributo, los bloques utilizados en el disco duro son escritos con ceros, de modo que los datos no se puedan recuperar por medio alguno. Es la forma más segura de eliminar datos.
S Cuando el fichero tiene este atributo, sus cambios son escritos de forma sincrónica en el disco duro. Es decir, los datos se escriben inmediatamente en lugar de esperar la operación correspondiente del sistema operativo. Es equivalente a la opción sync del mandato mount.
u Cuando un fichero con este atributo es eliminado, sus contenidos son guardados permitiendo recuperar el fichero con herramientas para tal fin.
Utilización.
chattr [-RV] +-=[AacDdijsSu] [-v versión] ficheros
Ejemplos.
el siguiente mandato agrega el atributo inmutable al fichero algo.txt..
chattr +i algo.txt
El siguiente mandato elimina el atributo inmutable al fichero algo.txt.
chattr -i algo.txt
El siguiente mandato agrega el modo de solo adjuntar para escritura al fichero algo.txt.
chattr +a algo.txt
El siguiente mandato elimina el modo de solo adjuntar para escritura al fichero algo.txt.
chattr -a algo.txt
El siguiente mandato establece que el fichero algo.txt solo tendrá los atributos a, A, s y S.
chattr =aAsS algo.txt
El siguiente mandato lista los atributos del fichero algo.txt.
lsattr algo.txt
En la mayoría de los casos, cuando un intruso consigue suficientes privilegios en un sistema, lo primero que hará será eliminar los registros de sus actividades modificando estructuras de los ficheros de bitácoras del sistema y otros componentes. Utilizar el mandato chattr ciertamente no es obstáculo para un usuario experto, pero, afortunadamente, la gran mayoría de los intrusos potenciales no suelen ser expertos en GNU/Linux o Unix, dependiendo enormemente de diversos programas o guiones (los denominados rootkits y zappers) para eliminar aquello que permita descubrir sus actividades.
Utilizar el mandato chattr, incluido en el paquete e2fsprogs, que se instala de forma predeterminada en todas las distribuciones de GNU/Linux por tratarse de un componente esencial, hace más difícil borrar o alterar bitácoras, ficheros de configuración y componentes del sistema. Theodore Ts'o es el desarrollador y quien se encarga de mantener e2fsprogs, mismo que se distribuye bajo los términos de la licencia GNU/GPL, e incluye otras herramientas como e2fsck, e2label, fsck.ext2, fsck.ext3, mkfs.ext2, mkfs.ext3, tune2fs y dumpe2fs, entre otras.
URL: http://e2fsprogs.sourceforge.net/
Opciones.
-R Cambia recursivamente los atributos de directorios y sus contenidos. Los enlaces simbólicos que se encuentren, son ignorado
-V Salida de charttr más descriptiva, mostrando además la versión del programa.
-v Ver el número de versión del programa.
Operadores.
+ Hace que se añadan los atributos especificados a los atributos existentes de un fichero.
- Hace que se eliminen los atributos especificados de los atributos existentes de un fichero
= Hace que solamente haya los atributos especificados.
Atributos.
A Establece que la fecha del último acceso (atime) no se modifica.
a Establece que el fichero solo se puede abrir en modo de adjuntar para escritura.
c Establece que el fichero es comprimido automáticamente en el disco por el núcleo del sistema operativo. Al realizar lectura de este fichero, se descomprimen los datos. La escritura de dicho fichero comprime los datos antes de almacenarlos en el disco.
D Cuando se trata de un directorio, establece que los datos se escriben de forma sincrónica en el disco. Es decir, los datos se escriben inmediatamente en lugar de esperar la operación correspondiente del sistema operativo. Es equivalente a la opción dirsync del mandato mount, pero aplicada a un subconjunto de ficheros.
d Establece que el fichero no sea candidato para respaldo al utilizar la herramienta dump.
i Establece que el fichero será inmutable. Es decir, no puede ser eliminado, ni renombrado, no se pueden apuntar enlaces simbólicos, ni escribir datos en el fichero.
j En los sistemas de ficheros ext3, cuando se montan con las opciones data=ordered o data=writeback, se establece que el fichero será escrito en el registro por diario (Journal). Si el sistema de ficheros se monta con la opción data=journal (opción predeterminada), todo el sistema de ficheros se escribe en el registro por diario y por lo tanto el atributo no tiene efecto.
s Cuando un fichero tiene este atributo, los bloques utilizados en el disco duro son escritos con ceros, de modo que los datos no se puedan recuperar por medio alguno. Es la forma más segura de eliminar datos.
S Cuando el fichero tiene este atributo, sus cambios son escritos de forma sincrónica en el disco duro. Es decir, los datos se escriben inmediatamente en lugar de esperar la operación correspondiente del sistema operativo. Es equivalente a la opción sync del mandato mount.
u Cuando un fichero con este atributo es eliminado, sus contenidos son guardados permitiendo recuperar el fichero con herramientas para tal fin.
Utilización.
chattr [-RV] +-=[AacDdijsSu] [-v versión] ficheros
Ejemplos.
el siguiente mandato agrega el atributo inmutable al fichero algo.txt..
chattr +i algo.txt
El siguiente mandato elimina el atributo inmutable al fichero algo.txt.
chattr -i algo.txt
El siguiente mandato agrega el modo de solo adjuntar para escritura al fichero algo.txt.
chattr +a algo.txt
El siguiente mandato elimina el modo de solo adjuntar para escritura al fichero algo.txt.
chattr -a algo.txt
El siguiente mandato establece que el fichero algo.txt solo tendrá los atributos a, A, s y S.
chattr =aAsS algo.txt
El siguiente mandato lista los atributos del fichero algo.txt.
lsattr algo.txt
Mandatos Chown y Chgrp
Tanto chown como chgrp, forman parte del paquete coreutils, el cual se instala de forma predeterminada en todas las distribuciones de GNU/Linux, por tratarse de un componente esencial.
URL: ftp://alpha.gnu.org/gnu/coreutils/
Mandato chown.
El mandato chown se utiliza para cambiar el propietario al que pertenece un fichero o directorio. Puede especificarse tanto el nombre de un usuario, así como un número de identidad de usuario (UID). Opcionalmente, utilizando un signo de dos puntos (:), o bien un punto (.), permite especificar también un nombre de grupo.
Opciones.
-R Cambia recursivamente el propietario (y, opcionalmente, el grupo al que pertenecen los directorios, junto con todos sus contenidos.
-v (o --verbose) Salida de chown más descriptiva.
--version Ver el número de versión del programa.
--dereference Actúa sobre enlaces simbólicos en lugar de hacerlo sobre el destino.
-h (o --no-dereference) En el caso de enlaces simbólicos, cambia el propietario del destino en lugar del propio enlace.
--reference Cambia el el propietario de un fichero, tomando como referencia el propietario de otro.
Utilización.
chown [opciones] usuario[:grupo] fichero(s) o directorio(s)
Mandato chgrp.
El mandato chgrp se utiliza para cambiar el grupo al que pertenece un fichero o directorio. Puede especificarse tanto el nombre de un grupo, así como un número de identidad de grupo (GID).
Opciones.
-R Cambia recursivamente el grupo al que pertenecen los directorios, junto con todos sus contenidos.
-v (o --verbose) Salida de chgrp más descriptiva.
--version Ver el número de versión del programa.
--dereference Actúa sobre enlaces simbólicos en lugar de hacerlo sobre el destino.
-h (o --no-dereference) En el caso de enlaces simbólicos, cambia el grupo del destino en lugar del propio enlace.
--reference Cambia el grupo de un fichero, tomando como referencia el propietario de otro.
Utilización.
chgrp [opciones] fichero(s) o directorio(s)
Ejemplos.
El siguiente mandato realiza el cambio de propietario a fulano, sobre el fichero algo.txt.
chown fulano algo.txt
El siguiente mandato realiza el cambio de propietario a fulano y el grupo desarrollo, sobre el fichero algo.txt.
chown fulano:desarrollo algo.txt
El siguiente mandato realiza el cambio de propietario a fulano y el grupo mail, del subdirectorio Mail, junto con todo su contenido.
chown -R fulano:mail Mail
El siguiente mandato realiza el cambio de grupo a desarrollo, sobre el fichero algo.txt.
chgrp desarrollo algo.txt
URL: ftp://alpha.gnu.org/gnu/coreutils/
Mandato chown.
El mandato chown se utiliza para cambiar el propietario al que pertenece un fichero o directorio. Puede especificarse tanto el nombre de un usuario, así como un número de identidad de usuario (UID). Opcionalmente, utilizando un signo de dos puntos (:), o bien un punto (.), permite especificar también un nombre de grupo.
Opciones.
-R Cambia recursivamente el propietario (y, opcionalmente, el grupo al que pertenecen los directorios, junto con todos sus contenidos.
-v (o --verbose) Salida de chown más descriptiva.
--version Ver el número de versión del programa.
--dereference Actúa sobre enlaces simbólicos en lugar de hacerlo sobre el destino.
-h (o --no-dereference) En el caso de enlaces simbólicos, cambia el propietario del destino en lugar del propio enlace.
--reference Cambia el el propietario de un fichero, tomando como referencia el propietario de otro.
Utilización.
chown [opciones] usuario[:grupo] fichero(s) o directorio(s)
Mandato chgrp.
El mandato chgrp se utiliza para cambiar el grupo al que pertenece un fichero o directorio. Puede especificarse tanto el nombre de un grupo, así como un número de identidad de grupo (GID).
Opciones.
-R Cambia recursivamente el grupo al que pertenecen los directorios, junto con todos sus contenidos.
-v (o --verbose) Salida de chgrp más descriptiva.
--version Ver el número de versión del programa.
--dereference Actúa sobre enlaces simbólicos en lugar de hacerlo sobre el destino.
-h (o --no-dereference) En el caso de enlaces simbólicos, cambia el grupo del destino en lugar del propio enlace.
--reference Cambia el grupo de un fichero, tomando como referencia el propietario de otro.
Utilización.
chgrp [opciones] fichero(s) o directorio(s)
Ejemplos.
El siguiente mandato realiza el cambio de propietario a fulano, sobre el fichero algo.txt.
chown fulano algo.txt
El siguiente mandato realiza el cambio de propietario a fulano y el grupo desarrollo, sobre el fichero algo.txt.
chown fulano:desarrollo algo.txt
El siguiente mandato realiza el cambio de propietario a fulano y el grupo mail, del subdirectorio Mail, junto con todo su contenido.
chown -R fulano:mail Mail
El siguiente mandato realiza el cambio de grupo a desarrollo, sobre el fichero algo.txt.
chgrp desarrollo algo.txt
Cómo configurar y utilizar Sudo.
Sudo es una herramienta de sistema que permite a los usuarios realizar la ejecución de mandatos como superusuario u otro usuario de acuerdo a como se especifique en el fichero /etc/sudoers, donde se determina quien está autorizado. Los números de identidad de usuario y de grupo (UID y GID) reales y efectivas se establecen para igualar a aquellas del usuario objetivo como esté especificado en el fichero /etc/passwd.
De modo predeterminado sudo requiere que los usuarios se autentiquen así mismos con su propia clave de acceso (nunca la clave de acceso de root). Una vez que el usuario se ha autenticado, el usuario podrá utilizar nuevamente sudo sin necesidad de volver a autenticarse durante 5 minutos, salvo que se especifique lo contrario en el fichero /etc/sudoers. Si el usuario ejecuta el mandato sudo -v podrá refrescar éste periodo de tiempo sin necesidad de tener que ejecutar un mandato, en cuyo caso contrario expirará esta autenticación y será necesario volver a realizarla.
Si un usuario no listado en el fichero /etc/sudoers. trata de ejecutar un mandato a través de sudo, se registra la actividad en la bitácora de sistema (a través de syslogd) y se envía un mensaje de correo electrónico al administrador del sistema (root).
Historia.
Sudo fue inicialmente concebido en 1980 por Bob Coggeshall y Cliff Spencer del departamento de ciencia computacional en SUNY (State University of New York o Universidad Estatal de Nueva York), en Buffalo.
En 1985 se publicó el grupo de noticias net.sources una versión mejorada acreditada a Phil Betchel, Cliff Spencer, Gretchen Phillips, John LoVerso y Don Gworek. Garth Snyder publicó otra versión mejorada en el verano de 1986 y durante los siguientes cinco años fue mantenido con al colaboración de muchas personas, incluyendo Bob Coggeshall, Bob Manchek, y Trent Hein.
En 1991 Dave Hieb y Jeff Nieusma escribieron una nueva versión con un formato mejorado para el fichero /etc/sudoers bajo contrato con la firma consultora The Root Group, versión que posteriormente fue publicada bajo los términos de la Licencia Pública General de GNU (GNU/GPL).
Desde 1996 el proyecto es mantenido por Todd Miller con la colaboración de Chris Jepeway y Aaron Spangler.
Fichero /etc/sudoers
El fichero /etc/sudoers se edita con el mandato visudo, herramienta que a través de vi permite realizar cambios y verificar sintaxis y errores. Si se trata de modificar directamente /etc/sudoers, éste tiene permisos de solo lectura.
La sintaxis básica de una lista sería:
XXXX_Alias NOMBRELISTA = elemento1, elemento2, elemento3
La sintaxis básica de una regla sería:
[usuario, %grupo, NOMBRELISTA] [anfitrión] = (id de usuario a usar) mandatos
Se pueden definir Aliases y reglas. Los aliases permiten definir una lista de mandatos , una lista de usuarios, un alista de anfitriones o bien ejecutar como otros usuarios.
Cmnd_Alias.
Cmnd_Alias MANDATOSHTTPD = /sbin/service httpd restart,
/usr/bin/vim /etc/httpd/conf.d/variables.conf,
/usr/bin/vim /etc/php.ini
Lo anterior define una lista de mandatos que podrían utilizarse para reiniciar el servicio de httpd, modificar un fichero de configuración en la ruta /etc/httpd/conf.d/variables.conf y modificar el fichero /etc/php.ini.
fulano ALL = MANDATOSHTTPD
Lo anterior define que el usuario fulano puede utilizar los mandatos de la lista MANDATOSHTTPD desde cualquier anfitrión.
User_Alias.
User_Alias USUARIOSHTTP = fulano, mengano, zutano
Lo anterior define una lista denominada HTTPUSERS, integrada por los usuarios fulano, mengano y zutano.
USUARIOSHTTP ALL = /usr/bin/vim
La regla anterior define que los usuarios que conforman la lista USUARIOSHTTP pueden utilizar el mandato vim desde cualquier anfitrión.
Host_Alias.
Host_Alias HOSTSHTTPD = 192.168.0.25, 192.168.0.26, 192.168.0.23
Lo anterior define que la lista HOSTSHTTPD está integrada por las 3 direcciones IP listadas anteriormente. Si además se añade la siguiente regla:
USUARIOSHTTPD HOSTSHTTPD = ADMINHTTPD
Lo anterior define que los usuarios de la lista HTTPDUSERS pueden utilizar los mandatos listados en ADMINHTTPD solamente si están conectados desde las direcciones IP listadas en HOSTSHTTPD.
Runas_Alias.
Si por ejemplo se quisiera que los usuarios de la lista USUARIOSHTTP pudieran además utilizar los mandatos ls, rm, chmod, cp, mv, mkdir, touch y vim como el usuarios juan, pedro y hugo, se requiere definir una lista para estos mandatos y otra para los aliases de usuarios alternos, y la regla correspondiente.
Runas_Alias CLIENTES1 = juan, pedro, hugo
Cmnd_Alias MANDATOSCLIENTES = /bin/ls,
/bin/rm,
/bin/chmod,
/bin/cp, /bin/mv,
/bin/mkdir,
/bin/touch,
/usr/bin/vim
USUARIOSHTTPD HOSTSHTTPD = (CLIENTES1) MANDATOSCLIENTES
Lo anterior permite a los usuarios definidos en USUARIOSHTTPD (fulano, mengano y zutano), utilizar los mandatos definidos en MANDATOSCLIENTES (ls, rm, chmod, cp, mv, mkdir, touch y vim) identificándose como los usuarios definidos en CLIENTES1 (juan, pedro y hugo) solamente si se realiza desde las direcciones IP listadas en HOSTSHTTPD (192.168.0.25, 192.168.0.26, 192.168.0.23).
Candados de seguridad.
Sudo incluye varios candados de seguridad que impiden se puedan realizar tareas peligrosas.
Si se define el mandato /usr/bin/vim en /etc/sudoers, se podrá hacer uso de éste de los siguientes modos:
$ sudo /usr/bin/vim
$ sudo vim
Sin embargo, no podrá ser utilizado así:
$ cd /usr/bin
$ sudo ./vim
Si se define el mandato /bin/echo, el usuario podrá utilizarlo de los siguientes modos:
$ sudo /bin/echo "Hola"
$ sudo echo "Hola"
Pero no podrá utilizarlo de la siguiente forma:
$ sudo echo "Hola" > algo.txt
Para poder realizar la operación anterior, tendría que utilizar:
$ sudo bash -c "echo 'Hola' > algo.txt"
Sudo permitirá realizar una tarea sobre cualquier fichero dentro de cualquier directorio aún si no tiene permisos de acceso para ingresar a dicho directorio siempre y cuando especifique la ruta exacta de dicho fichero.
$ sudo chown named /var/named/dominio.zone
Pero no podrá utilizarlo así:
$ sudo chown named /var/named/*.zone
Lo que no se recomienda.
Si se quiere permitir a un usuario utilizar lo que sea, desde cualquier anfitrión, cómo cualquier usuario del sistema y sin necesidad de autenticar, se puede simplemente definir:
fulano ALL = (ALL) NOPASSWD: ALL
Facilitando la vida a través de ~/.bash_profile.
BASH (Bourne-Again Shell) permite utilizar variables de entorno y aliases definidas en ~/.bash_profile al iniciar la sesión, siendo que el administrador utilizará activamente muchos mandatos diversos, estos se pueden simplificar a través de aliases que resuman éstos. Por ejemplo, si se quiere definir que se utilice sudo cada vez que se invoque al mandato chkconfig, se puede añadir lo siguiente al fichero ~/.bash_profile:
alias chkconfig="sudo /sbin/chkconfig"
Lo anterior permitirá ejecutar directamente el mandato chkconfig sin necesidad de preceder éste con el mandato sudo. A continuación só diversos aliases que pueden ser de utilidad en el fichero ~/.bash_profile y que permitirán utilizar mandatos diversos con sudo.
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin:/sbin:/usr/sbin
export PATH
unset USERNAME
alias chkconfig="sudo /sbin/chkconfig"
alias service="sudo /sbin/service"
alias route="sudo /sbin/route"
alias depmod="sudo /sbin/depmod"
alias ifconfig="sudo /sbin/ifconfig"
alias chmod="sudo /bin/chmod"
alias chown="sudo /bin/chown"
alias chgrp="sudo /bin/chgrp"
alias useradd="sudo /usr/sbin/useradd"
alias userdel="sudo /usr/sbin/userdel"
alias groupadd="sudo /usr/sbin/groupadd"
alias groupdel="sudo /usr/sbin/groupdel"
alias edquota="sudo /usr/sbin/edquota"
alias vi="sudo /usr/bin/vim"
alias less="sudo /usr/bin/less"
alias tail="sudo /usr/bin/tail"
alias yum="sudo /usr/bin/yum"
alias saslpasswd2="sudo /usr/sbin/saslpasswd2"
alias htpasswd="sudo /usr/bin/htpasswd"
alias openssl="sudo /usr/bin/openssl"
alias system-config-printer="sudo /usr/sbin/system-config-printer"
alias system-config-network="sudo /usr/sbin/system-config-network"
alias system-config-display="sudo /usr/bin/system-config-display"
Para que surtan efectos los cambios, hay que salir de la sesión y volver a ingresar al sistema con la misma cuenta de usuario, en cuyo fichero ~/.bash_profile se añadieron estos aliases.
De modo predeterminado sudo requiere que los usuarios se autentiquen así mismos con su propia clave de acceso (nunca la clave de acceso de root). Una vez que el usuario se ha autenticado, el usuario podrá utilizar nuevamente sudo sin necesidad de volver a autenticarse durante 5 minutos, salvo que se especifique lo contrario en el fichero /etc/sudoers. Si el usuario ejecuta el mandato sudo -v podrá refrescar éste periodo de tiempo sin necesidad de tener que ejecutar un mandato, en cuyo caso contrario expirará esta autenticación y será necesario volver a realizarla.
Si un usuario no listado en el fichero /etc/sudoers. trata de ejecutar un mandato a través de sudo, se registra la actividad en la bitácora de sistema (a través de syslogd) y se envía un mensaje de correo electrónico al administrador del sistema (root).
Historia.
Sudo fue inicialmente concebido en 1980 por Bob Coggeshall y Cliff Spencer del departamento de ciencia computacional en SUNY (State University of New York o Universidad Estatal de Nueva York), en Buffalo.
En 1985 se publicó el grupo de noticias net.sources una versión mejorada acreditada a Phil Betchel, Cliff Spencer, Gretchen Phillips, John LoVerso y Don Gworek. Garth Snyder publicó otra versión mejorada en el verano de 1986 y durante los siguientes cinco años fue mantenido con al colaboración de muchas personas, incluyendo Bob Coggeshall, Bob Manchek, y Trent Hein.
En 1991 Dave Hieb y Jeff Nieusma escribieron una nueva versión con un formato mejorado para el fichero /etc/sudoers bajo contrato con la firma consultora The Root Group, versión que posteriormente fue publicada bajo los términos de la Licencia Pública General de GNU (GNU/GPL).
Desde 1996 el proyecto es mantenido por Todd Miller con la colaboración de Chris Jepeway y Aaron Spangler.
Fichero /etc/sudoers
El fichero /etc/sudoers se edita con el mandato visudo, herramienta que a través de vi permite realizar cambios y verificar sintaxis y errores. Si se trata de modificar directamente /etc/sudoers, éste tiene permisos de solo lectura.
La sintaxis básica de una lista sería:
XXXX_Alias NOMBRELISTA = elemento1, elemento2, elemento3
La sintaxis básica de una regla sería:
[usuario, %grupo, NOMBRELISTA] [anfitrión] = (id de usuario a usar) mandatos
Se pueden definir Aliases y reglas. Los aliases permiten definir una lista de mandatos , una lista de usuarios, un alista de anfitriones o bien ejecutar como otros usuarios.
Cmnd_Alias.
Cmnd_Alias MANDATOSHTTPD = /sbin/service httpd restart,
/usr/bin/vim /etc/httpd/conf.d/variables.conf,
/usr/bin/vim /etc/php.ini
Lo anterior define una lista de mandatos que podrían utilizarse para reiniciar el servicio de httpd, modificar un fichero de configuración en la ruta /etc/httpd/conf.d/variables.conf y modificar el fichero /etc/php.ini.
fulano ALL = MANDATOSHTTPD
Lo anterior define que el usuario fulano puede utilizar los mandatos de la lista MANDATOSHTTPD desde cualquier anfitrión.
User_Alias.
User_Alias USUARIOSHTTP = fulano, mengano, zutano
Lo anterior define una lista denominada HTTPUSERS, integrada por los usuarios fulano, mengano y zutano.
USUARIOSHTTP ALL = /usr/bin/vim
La regla anterior define que los usuarios que conforman la lista USUARIOSHTTP pueden utilizar el mandato vim desde cualquier anfitrión.
Host_Alias.
Host_Alias HOSTSHTTPD = 192.168.0.25, 192.168.0.26, 192.168.0.23
Lo anterior define que la lista HOSTSHTTPD está integrada por las 3 direcciones IP listadas anteriormente. Si además se añade la siguiente regla:
USUARIOSHTTPD HOSTSHTTPD = ADMINHTTPD
Lo anterior define que los usuarios de la lista HTTPDUSERS pueden utilizar los mandatos listados en ADMINHTTPD solamente si están conectados desde las direcciones IP listadas en HOSTSHTTPD.
Runas_Alias.
Si por ejemplo se quisiera que los usuarios de la lista USUARIOSHTTP pudieran además utilizar los mandatos ls, rm, chmod, cp, mv, mkdir, touch y vim como el usuarios juan, pedro y hugo, se requiere definir una lista para estos mandatos y otra para los aliases de usuarios alternos, y la regla correspondiente.
Runas_Alias CLIENTES1 = juan, pedro, hugo
Cmnd_Alias MANDATOSCLIENTES = /bin/ls,
/bin/rm,
/bin/chmod,
/bin/cp, /bin/mv,
/bin/mkdir,
/bin/touch,
/usr/bin/vim
USUARIOSHTTPD HOSTSHTTPD = (CLIENTES1) MANDATOSCLIENTES
Lo anterior permite a los usuarios definidos en USUARIOSHTTPD (fulano, mengano y zutano), utilizar los mandatos definidos en MANDATOSCLIENTES (ls, rm, chmod, cp, mv, mkdir, touch y vim) identificándose como los usuarios definidos en CLIENTES1 (juan, pedro y hugo) solamente si se realiza desde las direcciones IP listadas en HOSTSHTTPD (192.168.0.25, 192.168.0.26, 192.168.0.23).
Candados de seguridad.
Sudo incluye varios candados de seguridad que impiden se puedan realizar tareas peligrosas.
Si se define el mandato /usr/bin/vim en /etc/sudoers, se podrá hacer uso de éste de los siguientes modos:
$ sudo /usr/bin/vim
$ sudo vim
Sin embargo, no podrá ser utilizado así:
$ cd /usr/bin
$ sudo ./vim
Si se define el mandato /bin/echo, el usuario podrá utilizarlo de los siguientes modos:
$ sudo /bin/echo "Hola"
$ sudo echo "Hola"
Pero no podrá utilizarlo de la siguiente forma:
$ sudo echo "Hola" > algo.txt
Para poder realizar la operación anterior, tendría que utilizar:
$ sudo bash -c "echo 'Hola' > algo.txt"
Sudo permitirá realizar una tarea sobre cualquier fichero dentro de cualquier directorio aún si no tiene permisos de acceso para ingresar a dicho directorio siempre y cuando especifique la ruta exacta de dicho fichero.
$ sudo chown named /var/named/dominio.zone
Pero no podrá utilizarlo así:
$ sudo chown named /var/named/*.zone
Lo que no se recomienda.
Si se quiere permitir a un usuario utilizar lo que sea, desde cualquier anfitrión, cómo cualquier usuario del sistema y sin necesidad de autenticar, se puede simplemente definir:
fulano ALL = (ALL) NOPASSWD: ALL
Facilitando la vida a través de ~/.bash_profile.
BASH (Bourne-Again Shell) permite utilizar variables de entorno y aliases definidas en ~/.bash_profile al iniciar la sesión, siendo que el administrador utilizará activamente muchos mandatos diversos, estos se pueden simplificar a través de aliases que resuman éstos. Por ejemplo, si se quiere definir que se utilice sudo cada vez que se invoque al mandato chkconfig, se puede añadir lo siguiente al fichero ~/.bash_profile:
alias chkconfig="sudo /sbin/chkconfig"
Lo anterior permitirá ejecutar directamente el mandato chkconfig sin necesidad de preceder éste con el mandato sudo. A continuación só diversos aliases que pueden ser de utilidad en el fichero ~/.bash_profile y que permitirán utilizar mandatos diversos con sudo.
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin:/sbin:/usr/sbin
export PATH
unset USERNAME
alias chkconfig="sudo /sbin/chkconfig"
alias service="sudo /sbin/service"
alias route="sudo /sbin/route"
alias depmod="sudo /sbin/depmod"
alias ifconfig="sudo /sbin/ifconfig"
alias chmod="sudo /bin/chmod"
alias chown="sudo /bin/chown"
alias chgrp="sudo /bin/chgrp"
alias useradd="sudo /usr/sbin/useradd"
alias userdel="sudo /usr/sbin/userdel"
alias groupadd="sudo /usr/sbin/groupadd"
alias groupdel="sudo /usr/sbin/groupdel"
alias edquota="sudo /usr/sbin/edquota"
alias vi="sudo /usr/bin/vim"
alias less="sudo /usr/bin/less"
alias tail="sudo /usr/bin/tail"
alias yum="sudo /usr/bin/yum"
alias saslpasswd2="sudo /usr/sbin/saslpasswd2"
alias htpasswd="sudo /usr/bin/htpasswd"
alias openssl="sudo /usr/bin/openssl"
alias system-config-printer="sudo /usr/sbin/system-config-printer"
alias system-config-network="sudo /usr/sbin/system-config-network"
alias system-config-display="sudo /usr/bin/system-config-display"
Para que surtan efectos los cambios, hay que salir de la sesión y volver a ingresar al sistema con la misma cuenta de usuario, en cuyo fichero ~/.bash_profile se añadieron estos aliases.
Cómo configurar y utilizar Sudo.
Sudo es una herramienta de sistema que permite a los usuarios realizar la ejecución de mandatos como superusuario u otro usuario de acuerdo a como se especifique en el fichero /etc/sudoers, donde se determina quien está autorizado. Los números de identidad de usuario y de grupo (UID y GID) reales y efectivas se establecen para igualar a aquellas del usuario objetivo como esté especificado en el fichero /etc/passwd.
De modo predeterminado sudo requiere que los usuarios se autentiquen así mismos con su propia clave de acceso (nunca la clave de acceso de root). Una vez que el usuario se ha autenticado, el usuario podrá utilizar nuevamente sudo sin necesidad de volver a autenticarse durante 5 minutos, salvo que se especifique lo contrario en el fichero /etc/sudoers. Si el usuario ejecuta el mandato sudo -v podrá refrescar éste periodo de tiempo sin necesidad de tener que ejecutar un mandato, en cuyo caso contrario expirará esta autenticación y será necesario volver a realizarla.
Si un usuario no listado en el fichero /etc/sudoers. trata de ejecutar un mandato a través de sudo, se registra la actividad en la bitácora de sistema (a través de syslogd) y se envía un mensaje de correo electrónico al administrador del sistema (root).
Historia.
Sudo fue inicialmente concebido en 1980 por Bob Coggeshall y Cliff Spencer del departamento de ciencia computacional en SUNY (State University of New York o Universidad Estatal de Nueva York), en Buffalo.
En 1985 se publicó el grupo de noticias net.sources una versión mejorada acreditada a Phil Betchel, Cliff Spencer, Gretchen Phillips, John LoVerso y Don Gworek. Garth Snyder publicó otra versión mejorada en el verano de 1986 y durante los siguientes cinco años fue mantenido con al colaboración de muchas personas, incluyendo Bob Coggeshall, Bob Manchek, y Trent Hein.
En 1991 Dave Hieb y Jeff Nieusma escribieron una nueva versión con un formato mejorado para el fichero /etc/sudoers bajo contrato con la firma consultora The Root Group, versión que posteriormente fue publicada bajo los términos de la Licencia Pública General de GNU (GNU/GPL).
Desde 1996 el proyecto es mantenido por Todd Miller con la colaboración de Chris Jepeway y Aaron Spangler.
Fichero /etc/sudoers
El fichero /etc/sudoers se edita con el mandato visudo, herramienta que a través de vi permite realizar cambios y verificar sintaxis y errores. Si se trata de modificar directamente /etc/sudoers, éste tiene permisos de solo lectura.
La sintaxis básica de una lista sería:
XXXX_Alias NOMBRELISTA = elemento1, elemento2, elemento3
La sintaxis básica de una regla sería:
[usuario, %grupo, NOMBRELISTA] [anfitrión] = (id de usuario a usar) mandatos
Se pueden definir Aliases y reglas. Los aliases permiten definir una lista de mandatos , una lista de usuarios, un alista de anfitriones o bien ejecutar como otros usuarios.
Cmnd_Alias.
Cmnd_Alias MANDATOSHTTPD = /sbin/service httpd restart,
/usr/bin/vim /etc/httpd/conf.d/variables.conf,
/usr/bin/vim /etc/php.ini
Lo anterior define una lista de mandatos que podrían utilizarse para reiniciar el servicio de httpd, modificar un fichero de configuración en la ruta /etc/httpd/conf.d/variables.conf y modificar el fichero /etc/php.ini.
fulano ALL = MANDATOSHTTPD
Lo anterior define que el usuario fulano puede utilizar los mandatos de la lista MANDATOSHTTPD desde cualquier anfitrión.
User_Alias.
User_Alias USUARIOSHTTP = fulano, mengano, zutano
Lo anterior define una lista denominada HTTPUSERS, integrada por los usuarios fulano, mengano y zutano.
USUARIOSHTTP ALL = /usr/bin/vim
La regla anterior define que los usuarios que conforman la lista USUARIOSHTTP pueden utilizar el mandato vim desde cualquier anfitrión.
Host_Alias.
Host_Alias HOSTSHTTPD = 192.168.0.25, 192.168.0.26, 192.168.0.23
Lo anterior define que la lista HOSTSHTTPD está integrada por las 3 direcciones IP listadas anteriormente. Si además se añade la siguiente regla:
USUARIOSHTTPD HOSTSHTTPD = ADMINHTTPD
Lo anterior define que los usuarios de la lista HTTPDUSERS pueden utilizar los mandatos listados en ADMINHTTPD solamente si están conectados desde las direcciones IP listadas en HOSTSHTTPD.
Runas_Alias.
Si por ejemplo se quisiera que los usuarios de la lista USUARIOSHTTP pudieran además utilizar los mandatos ls, rm, chmod, cp, mv, mkdir, touch y vim como el usuarios juan, pedro y hugo, se requiere definir una lista para estos mandatos y otra para los aliases de usuarios alternos, y la regla correspondiente.
Runas_Alias CLIENTES1 = juan, pedro, hugo
Cmnd_Alias MANDATOSCLIENTES = /bin/ls,
/bin/rm,
/bin/chmod,
/bin/cp, /bin/mv,
/bin/mkdir,
/bin/touch,
/usr/bin/vim
USUARIOSHTTPD HOSTSHTTPD = (CLIENTES1) MANDATOSCLIENTES
Lo anterior permite a los usuarios definidos en USUARIOSHTTPD (fulano, mengano y zutano), utilizar los mandatos definidos en MANDATOSCLIENTES (ls, rm, chmod, cp, mv, mkdir, touch y vim) identificándose como los usuarios definidos en CLIENTES1 (juan, pedro y hugo) solamente si se realiza desde las direcciones IP listadas en HOSTSHTTPD (192.168.0.25, 192.168.0.26, 192.168.0.23).
Candados de seguridad.
Sudo incluye varios candados de seguridad que impiden se puedan realizar tareas peligrosas.
Si se define el mandato /usr/bin/vim en /etc/sudoers, se podrá hacer uso de éste de los siguientes modos:
$ sudo /usr/bin/vim
$ sudo vim
Sin embargo, no podrá ser utilizado así:
$ cd /usr/bin
$ sudo ./vim
Si se define el mandato /bin/echo, el usuario podrá utilizarlo de los siguientes modos:
$ sudo /bin/echo "Hola"
$ sudo echo "Hola"
Pero no podrá utilizarlo de la siguiente forma:
$ sudo echo "Hola" > algo.txt
Para poder realizar la operación anterior, tendría que utilizar:
$ sudo bash -c "echo 'Hola' > algo.txt"
Sudo permitirá realizar una tarea sobre cualquier fichero dentro de cualquier directorio aún si no tiene permisos de acceso para ingresar a dicho directorio siempre y cuando especifique la ruta exacta de dicho fichero.
$ sudo chown named /var/named/dominio.zone
Pero no podrá utilizarlo así:
$ sudo chown named /var/named/*.zone
Lo que no se recomienda.
Si se quiere permitir a un usuario utilizar lo que sea, desde cualquier anfitrión, cómo cualquier usuario del sistema y sin necesidad de autenticar, se puede simplemente definir:
fulano ALL = (ALL) NOPASSWD: ALL
Facilitando la vida a través de ~/.bash_profile.
BASH (Bourne-Again Shell) permite utilizar variables de entorno y aliases definidas en ~/.bash_profile al iniciar la sesión, siendo que el administrador utilizará activamente muchos mandatos diversos, estos se pueden simplificar a través de aliases que resuman éstos. Por ejemplo, si se quiere definir que se utilice sudo cada vez que se invoque al mandato chkconfig, se puede añadir lo siguiente al fichero ~/.bash_profile:
alias chkconfig="sudo /sbin/chkconfig"
Lo anterior permitirá ejecutar directamente el mandato chkconfig sin necesidad de preceder éste con el mandato sudo. A continuación só diversos aliases que pueden ser de utilidad en el fichero ~/.bash_profile y que permitirán utilizar mandatos diversos con sudo.
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin:/sbin:/usr/sbin
export PATH
unset USERNAME
alias chkconfig="sudo /sbin/chkconfig"
alias service="sudo /sbin/service"
alias route="sudo /sbin/route"
alias depmod="sudo /sbin/depmod"
alias ifconfig="sudo /sbin/ifconfig"
alias chmod="sudo /bin/chmod"
alias chown="sudo /bin/chown"
alias chgrp="sudo /bin/chgrp"
alias useradd="sudo /usr/sbin/useradd"
alias userdel="sudo /usr/sbin/userdel"
alias groupadd="sudo /usr/sbin/groupadd"
alias groupdel="sudo /usr/sbin/groupdel"
alias edquota="sudo /usr/sbin/edquota"
alias vi="sudo /usr/bin/vim"
alias less="sudo /usr/bin/less"
alias tail="sudo /usr/bin/tail"
alias yum="sudo /usr/bin/yum"
alias saslpasswd2="sudo /usr/sbin/saslpasswd2"
alias htpasswd="sudo /usr/bin/htpasswd"
alias openssl="sudo /usr/bin/openssl"
alias system-config-printer="sudo /usr/sbin/system-config-printer"
alias system-config-network="sudo /usr/sbin/system-config-network"
alias system-config-display="sudo /usr/bin/system-config-display"
Para que surtan efectos los cambios, hay que salir de la sesión y volver a ingresar al sistema con la misma cuenta de usuario, en cuyo fichero ~/.bash_profile se añadieron estos aliases.
De modo predeterminado sudo requiere que los usuarios se autentiquen así mismos con su propia clave de acceso (nunca la clave de acceso de root). Una vez que el usuario se ha autenticado, el usuario podrá utilizar nuevamente sudo sin necesidad de volver a autenticarse durante 5 minutos, salvo que se especifique lo contrario en el fichero /etc/sudoers. Si el usuario ejecuta el mandato sudo -v podrá refrescar éste periodo de tiempo sin necesidad de tener que ejecutar un mandato, en cuyo caso contrario expirará esta autenticación y será necesario volver a realizarla.
Si un usuario no listado en el fichero /etc/sudoers. trata de ejecutar un mandato a través de sudo, se registra la actividad en la bitácora de sistema (a través de syslogd) y se envía un mensaje de correo electrónico al administrador del sistema (root).
Historia.
Sudo fue inicialmente concebido en 1980 por Bob Coggeshall y Cliff Spencer del departamento de ciencia computacional en SUNY (State University of New York o Universidad Estatal de Nueva York), en Buffalo.
En 1985 se publicó el grupo de noticias net.sources una versión mejorada acreditada a Phil Betchel, Cliff Spencer, Gretchen Phillips, John LoVerso y Don Gworek. Garth Snyder publicó otra versión mejorada en el verano de 1986 y durante los siguientes cinco años fue mantenido con al colaboración de muchas personas, incluyendo Bob Coggeshall, Bob Manchek, y Trent Hein.
En 1991 Dave Hieb y Jeff Nieusma escribieron una nueva versión con un formato mejorado para el fichero /etc/sudoers bajo contrato con la firma consultora The Root Group, versión que posteriormente fue publicada bajo los términos de la Licencia Pública General de GNU (GNU/GPL).
Desde 1996 el proyecto es mantenido por Todd Miller con la colaboración de Chris Jepeway y Aaron Spangler.
Fichero /etc/sudoers
El fichero /etc/sudoers se edita con el mandato visudo, herramienta que a través de vi permite realizar cambios y verificar sintaxis y errores. Si se trata de modificar directamente /etc/sudoers, éste tiene permisos de solo lectura.
La sintaxis básica de una lista sería:
XXXX_Alias NOMBRELISTA = elemento1, elemento2, elemento3
La sintaxis básica de una regla sería:
[usuario, %grupo, NOMBRELISTA] [anfitrión] = (id de usuario a usar) mandatos
Se pueden definir Aliases y reglas. Los aliases permiten definir una lista de mandatos , una lista de usuarios, un alista de anfitriones o bien ejecutar como otros usuarios.
Cmnd_Alias.
Cmnd_Alias MANDATOSHTTPD = /sbin/service httpd restart,
/usr/bin/vim /etc/httpd/conf.d/variables.conf,
/usr/bin/vim /etc/php.ini
Lo anterior define una lista de mandatos que podrían utilizarse para reiniciar el servicio de httpd, modificar un fichero de configuración en la ruta /etc/httpd/conf.d/variables.conf y modificar el fichero /etc/php.ini.
fulano ALL = MANDATOSHTTPD
Lo anterior define que el usuario fulano puede utilizar los mandatos de la lista MANDATOSHTTPD desde cualquier anfitrión.
User_Alias.
User_Alias USUARIOSHTTP = fulano, mengano, zutano
Lo anterior define una lista denominada HTTPUSERS, integrada por los usuarios fulano, mengano y zutano.
USUARIOSHTTP ALL = /usr/bin/vim
La regla anterior define que los usuarios que conforman la lista USUARIOSHTTP pueden utilizar el mandato vim desde cualquier anfitrión.
Host_Alias.
Host_Alias HOSTSHTTPD = 192.168.0.25, 192.168.0.26, 192.168.0.23
Lo anterior define que la lista HOSTSHTTPD está integrada por las 3 direcciones IP listadas anteriormente. Si además se añade la siguiente regla:
USUARIOSHTTPD HOSTSHTTPD = ADMINHTTPD
Lo anterior define que los usuarios de la lista HTTPDUSERS pueden utilizar los mandatos listados en ADMINHTTPD solamente si están conectados desde las direcciones IP listadas en HOSTSHTTPD.
Runas_Alias.
Si por ejemplo se quisiera que los usuarios de la lista USUARIOSHTTP pudieran además utilizar los mandatos ls, rm, chmod, cp, mv, mkdir, touch y vim como el usuarios juan, pedro y hugo, se requiere definir una lista para estos mandatos y otra para los aliases de usuarios alternos, y la regla correspondiente.
Runas_Alias CLIENTES1 = juan, pedro, hugo
Cmnd_Alias MANDATOSCLIENTES = /bin/ls,
/bin/rm,
/bin/chmod,
/bin/cp, /bin/mv,
/bin/mkdir,
/bin/touch,
/usr/bin/vim
USUARIOSHTTPD HOSTSHTTPD = (CLIENTES1) MANDATOSCLIENTES
Lo anterior permite a los usuarios definidos en USUARIOSHTTPD (fulano, mengano y zutano), utilizar los mandatos definidos en MANDATOSCLIENTES (ls, rm, chmod, cp, mv, mkdir, touch y vim) identificándose como los usuarios definidos en CLIENTES1 (juan, pedro y hugo) solamente si se realiza desde las direcciones IP listadas en HOSTSHTTPD (192.168.0.25, 192.168.0.26, 192.168.0.23).
Candados de seguridad.
Sudo incluye varios candados de seguridad que impiden se puedan realizar tareas peligrosas.
Si se define el mandato /usr/bin/vim en /etc/sudoers, se podrá hacer uso de éste de los siguientes modos:
$ sudo /usr/bin/vim
$ sudo vim
Sin embargo, no podrá ser utilizado así:
$ cd /usr/bin
$ sudo ./vim
Si se define el mandato /bin/echo, el usuario podrá utilizarlo de los siguientes modos:
$ sudo /bin/echo "Hola"
$ sudo echo "Hola"
Pero no podrá utilizarlo de la siguiente forma:
$ sudo echo "Hola" > algo.txt
Para poder realizar la operación anterior, tendría que utilizar:
$ sudo bash -c "echo 'Hola' > algo.txt"
Sudo permitirá realizar una tarea sobre cualquier fichero dentro de cualquier directorio aún si no tiene permisos de acceso para ingresar a dicho directorio siempre y cuando especifique la ruta exacta de dicho fichero.
$ sudo chown named /var/named/dominio.zone
Pero no podrá utilizarlo así:
$ sudo chown named /var/named/*.zone
Lo que no se recomienda.
Si se quiere permitir a un usuario utilizar lo que sea, desde cualquier anfitrión, cómo cualquier usuario del sistema y sin necesidad de autenticar, se puede simplemente definir:
fulano ALL = (ALL) NOPASSWD: ALL
Facilitando la vida a través de ~/.bash_profile.
BASH (Bourne-Again Shell) permite utilizar variables de entorno y aliases definidas en ~/.bash_profile al iniciar la sesión, siendo que el administrador utilizará activamente muchos mandatos diversos, estos se pueden simplificar a través de aliases que resuman éstos. Por ejemplo, si se quiere definir que se utilice sudo cada vez que se invoque al mandato chkconfig, se puede añadir lo siguiente al fichero ~/.bash_profile:
alias chkconfig="sudo /sbin/chkconfig"
Lo anterior permitirá ejecutar directamente el mandato chkconfig sin necesidad de preceder éste con el mandato sudo. A continuación só diversos aliases que pueden ser de utilidad en el fichero ~/.bash_profile y que permitirán utilizar mandatos diversos con sudo.
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin:/sbin:/usr/sbin
export PATH
unset USERNAME
alias chkconfig="sudo /sbin/chkconfig"
alias service="sudo /sbin/service"
alias route="sudo /sbin/route"
alias depmod="sudo /sbin/depmod"
alias ifconfig="sudo /sbin/ifconfig"
alias chmod="sudo /bin/chmod"
alias chown="sudo /bin/chown"
alias chgrp="sudo /bin/chgrp"
alias useradd="sudo /usr/sbin/useradd"
alias userdel="sudo /usr/sbin/userdel"
alias groupadd="sudo /usr/sbin/groupadd"
alias groupdel="sudo /usr/sbin/groupdel"
alias edquota="sudo /usr/sbin/edquota"
alias vi="sudo /usr/bin/vim"
alias less="sudo /usr/bin/less"
alias tail="sudo /usr/bin/tail"
alias yum="sudo /usr/bin/yum"
alias saslpasswd2="sudo /usr/sbin/saslpasswd2"
alias htpasswd="sudo /usr/bin/htpasswd"
alias openssl="sudo /usr/bin/openssl"
alias system-config-printer="sudo /usr/sbin/system-config-printer"
alias system-config-network="sudo /usr/sbin/system-config-network"
alias system-config-display="sudo /usr/bin/system-config-display"
Para que surtan efectos los cambios, hay que salir de la sesión y volver a ingresar al sistema con la misma cuenta de usuario, en cuyo fichero ~/.bash_profile se añadieron estos aliases.
lunes, 16 de junio de 2008
Introducción a PostgreSQL - Instalación e inicialización
En este artículo vamos a dar una introducción a la base de datos PostgreSQL, tambien veremos como instalarla e inicializarla para empezar a utilizarla.
Introducción
Introducción
PostgreSQL es una base de datos relacional, distribuida bajo licencia BSD y con su código fuente disponible libremente. Es el motor de bases de datos de código abierto más potente del momento y en sus últimas versiones empieza a no tener que envidiarle nada a otras bases de datos comerciales.
Sus características técnicas la hacen una de las bases de datos más potentes y robustas del mercado. Su desarrollo comenzo hace más de 15 años, y durante este tiempo, estabilidad, potencia, robustez, facilidad de administración e implementación de estándares han sido las características que más se han tenido en cuenta durante su desarrollo. En los últimos años se han concentrado mucho en la velocidad de proceso y en características demandadas en el mundo empresarial.
La última serie de producción es la 8.2, siendo la última versión disponible en el momento de escribir este artículo la 8.2.4. PostgreSQL se puede ejecutar en la gran mayoria de sistemas operativos existentes en la actualidad, entre ellos Linux y UNIX en todas sus variantes (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows. Las características más importantes y soportadas son:
-Es una base de datos 100% ACID
-Llaves ajenas (foreign keys)
-Joins
-Vistas (views)
-Disparadores (triggers)
-Reglas (Rules)
-Funciones/procedimientos almacenados (stored procedures) en numerosos lenguajes de programacion, entre otros PL/pgSQL (similar al PL/SQL de oracle)
-Numerosos tipos de datos, posibilidades de definir nuevos tipos
-Soporta el almacenamiento de objetos binarios grandes (gráficos, videos, sonido, ...)
-Herencia de tablas (Inheritance)
-PITR - point in time recovery
-Tablespaces
-Replicación asincrona
-Nested transactions (savepoints)
-Two-phase commit
-Copias de seguridad en caliente (Online/hot backups)
-Unicode
-Juegos de caracteres internacionales
-Multi-Version Concurrency Control (MVCC)
-Acceso encriptado via SSL
-SQL92/SQL99
-APIs para programar en C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, PHP y muchos otros lenguajes.
-Completa documentacion
Otra caracteristica muy a tener en cuenta es lo bien que PostgreSQL funciona con grandes cantidades de datos y una alta concurrencia, con muchos usuarios accediendo a la vez el sistema. En un futuro escribiremos un artículo sobre esto.
Algunos de los limites físicos de PostgreSQL son:
Limite Valor
--------------------------------------------------------------------
Maximo tamaño base de dato Ilimitado (Depende de tu sistema de almacenamiento)
Maximo tamaño de tabla 32 TB
Maximo tamaño de fila 1.6 TB
Maximo tamaño de campo 1 GB
Maximo numero de filas por tabla Ilimitado
Maximo numero de columnas por tabla 250 - 1600 (dependiendo del tipo)
Maximo numero de indices por tabla Ilimitado
--------------------------------------------------------------------
Podriamos seguir escribiendo sobre muchas más características, pero en este artículo no tienen cabida. Podeis pasaros por la pagina web del proyecto, Postgresql.org para profundizar en el tema ó estar atentos a una serie de artículos sobre PostgreSQL que iremos publicando en el futuro .
A continución pasaremos a describir como podemos instalar e inicizalizar PosgreSQL.
Instalación
PostgreSQL está disponible en cualquiera de las principales distribuciones de Linux. Existen paquetes RPM og DEB, que se distribuyen con estas distribuciones y que se pueden instalar de la manera por defecto típica en cada distribución.
Si quereis instalar PostgreSQL de esta manera, adelante, es totalmente valida. A mi particularmente, el motor de base de datos que utilizo me gusta compilarlo e instalarlo yo mismo desde las fuentes. De esta manera tengo control absoluto sobre la versión en uso (especialmente importante en sistemas en producción y bases de datos). El resto del artículo se basa en este tipo de instalación.
Requerimientos
Se necesitan una serie de programas para poder compilar e instalar PostgreSQL (o cualquier otro programa) desde las fuentes. La mayoria de lo que se necesita se suele instalar por defecto en la mayoria de las distribuciones si instalamos los paquetes relacionados con "Desarrollo y compiladores". Todos estos paquetes se pueden instalar de la manera estandard, rpm og deb en la distribucion de Linux que utiliceis, si por causalidad no los teneis instalados.
Necesitamos:
+GNU make (gmake)
+Un compilador ISO/ANSI C. GCC el compilador por defecto en Linux funciona perfectamente.
+tar, gzip o bzip2 para desempaquetar las fuentes.
+Biblioteca GNU Readline
+Biblioteca de compresión zlib
+Perl y python si quereis soportar PL/Perl y PL/Python
Compilación e instalación
Primero nos bajamos las fuentes de la versión que vayamos a instalar de Postgresql.org. En nuestro ejemplo la versión 8.2.4 desde el servidor espejo (mirror) de Noruega.
[user@servidor]# cd /tmp/
[user@servidor]# wget ftp://ftp.no.postgresql.org/pub/databases/postgresql/source/v8.2.4/postgresql-8.2.4.tar.bz2
--21:17:45-- ftp://ftp.no.postgresql.org/pub/databases/postgresql/source/v8.2.4/postgresql-8.2.4.tar.bz2
=> `postgresql-8.2.4.tar.bz2'
Resolving ftp.no.postgresql.org... 158.36.2.10
Connecting to ftp.no.postgresql.org158.36.2.10:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /pub/databases/postgresql/source/v8.2.4 ... done.
==> PASV ... done. ==> RETR postgresql-8.2.4.tar.bz2 ... done.
Length: 12,527,803 (12M) (unauthoritative)
100%[===========================================================>] 12,527,803 692.34K/s ETA 00:00
21:18:02 (700.20 KB/s) - `postgresql-8.2.4.tar.bz2' saved [12527803]
A partir de ahora seguimos trabajamos como usuario root.:
[user@servidor]# su -
(o sudo -i si estamos en Ubuntu)
Desempaquetamos las fuentes:
[root@servidor]# cd /tmp
[root@servidor]# tar xjvf postgresql-8.2.4.tar.bz2
[root@servidor]# cd postgresql-8.2.4/
Ahora tenemos que configurar y compilar PostgreSQL. Existen muchos parametros que podemos utilizar para configurar las caracteristicas disponibles en el software PostgreSQL que vamos a compilar. Teneis una lista completa sobre estos parametros en la sección 14.5.Installation Procedure de la documentación oficial de PostgreSQL.
Para mis servidores en producción, yo suelo configurar PostgreSQL con estos parametros:
[root@servidor]# ./configure --prefix=/usr/local --enable-nls --with-perl --with-python --with-openssl --with-pam --with-ldap
Estos parametros necesitan que tengais instalado en vuestro sistema perl, python, openssl y ldap (estos paquetes se pueden instalar de la manera estandard, rpm og deb en la distribucion de Linux que utiliceis).
Para instalar en casa seguramente no necesiteis --with-pam --with-ldap, el resto es bueno tenerlo para tener posibilidad de conectar a vuestra base de datos encriptando el trafico de red, y tener posibilidad de utilizar PL/Perl y PL/Python para crear funciones. Mas información en PL/Perl - Perl Procedural Language y PL/Python - Python Procedural Language
Una vez que el proceso de configuración este terminado sin errores, podemos empezar a compilar las fuentes:
[root@servidor]# gmake
La compilación deberia de terminar sin errores si tenemos instalado todos los paquetes que necesitamos y dependiendo de los parametros de configuración que hayamos definido con ./configure.
Una vez que hayamos terminado de compilar las fuentes, pasamos a instalar todos los programas que forman PostgreSQL:
[root@servidor]# gmake install
Si todo ha salido bien, ahora tendremos todo lo necesario para usar PostgreSQL (servidor, clientes, herramientas, bibliotecas, etc) disponible en nuestro sistema. En nuestro ejemplo todo se habrá instalado bajo /usr/local (como definimos más arriba con --prefix=/usr/local)
Inicialización
Ahora tenemos que inicializar y configurar nuestra instalación de PostgreSQL antes de poder empezar a crear nuetra base de datos.
Lo primero que tenemos que hacer es crear un usuario en el sistema (postgres), que será el dueño en nuestro sistema de los ficheros generados por PostgreSQL, asi como el encargado de ejecutar el motor de base de datos (PostgreSQL se negará a arrancar si intentamos hacerlo como usuario root)
Podeis utilizar vuestro programa preferido para crear nuevos usuarios en vuestra distribución, o ejecutar el siguiente comando:
[root@servidor]# useradd --help
Usage: useradd ...
useradd - create a new user
-c comment Set the GECOS field for the new account
--show-defaults Print default values
--save-defaults Save modified default values
-D binddn Use dn "binddn" to bind to the LDAP directory
-d homedir Home directory for the new user
-e expire Date on which the new account will be disabled
-f inactive Days after a password expires until account is disabled
-G group,... List of supplementary groups
-g gid Name/number of the users primary group
-k skeldir Specify an alternative skel directory
-m Create home directory for the new user
-o Allow duplicate (non-unique) UID
-P path Search passwd, shadow and group file in "path"
-p password Encrypted password as returned by crypt(3)
-u uid Force the new userid to be the given number
-r, --system Create a system account
-s shell Name of the user's login shell
--service srv Add account to nameservice 'srv'
--help Give this help list
--usage Give a short usage message
-v, --version Print program version
Valid services for --service are: files, ldap
[root@servidor]# useradd -m postgres
Hemos creado nuestro usuario postgres sin clave de acceso. Esto significa que la unica manera de convertirse en este usuario es siendo root y utilizando el comando su - postgres.
A continuación nos conectamos como el usuario postgres e inicializamos nuestro "cluster postgresql".
[root@servidor] mkdir -p /var/pgsql/data
[root@servidor] chown postgres /var/pgsql/data
[root@servidor]# su - postgres
[postgres@servidor]# /usr/local/bin/initdb -E utf8 -U postgres -D /var/pgsql/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale en_US.UTF-8.
fixing permissions on existing directory /var/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating configuration files ... ok
creating template1 database in /var/pgsql/data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.
Success. You can now start the database server using:
/usr/local/bin/postgres -D /var/pgsql/data
or
/usr/local/bin/pg_ctl -D /var/pgsql/data -l logfile start
Suponemos que vamos a tener todas nuetras bases de datos y ficheros relacionados con postgresql en el directorio /var/pgsql/data.
En sucesivos artículos, veremos como podemos configurar/organizar nuestros discos de una mejor manera para conseguir la máxima seguridad y velocidad cuando utilicemos PostgreSQL en sistemas de producción. Tambien, veremos como podemos configurar PostgreSQL para sacar el maximo provecho a esta magnifica base de datos.
En estos momentos podemos arrancar nuestra base de datos postgresql y empezar a utilizarla sin problemas.
[postgres@servidor]# /usr/local/bin/pg_ctl -D /var/pgsql/data -l /var/pgsql/data/postgresql.log start
server starting
Si queremos parar PostgreSQL podemos utilizar el siguiente comando:
[postgres@servidor]# /usr/local/bin/pg_ctl -D /var/pgsql/data stop -m fast
waiting for server to shut down.... done
server stopped
Podemos empezar a utilizar la base de datos con el potentisimo cliente por linea de comandos que se instala por defecto, su nombre /usr/local/bin/psql:
[postgres@servidor]# /usr/local/bin/psql
Welcome to psql 8.2.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
postgres=#
Para conseguir una lista de los principales comandos que podeis utilizar en psql para que podais empezar a disfrutar de PostgreSQL, ejecutar el comando \?:
postgres=# \?
Aqui teneis algunos ejemplos de como utilizar este cliente :
postgres=# \l
List of databases
Name Owner Encoding
-----------+----------+----------
postgres postgres UTF8
template0 postgres UTF8
template1 postgres UTF8
(3 rows)
postgres=# CREATE DATABASE test001;
CREATE DATABASE
postgres=# \l
List of databases
Name Owner Encoding
-----------+----------+----------
postgres postgres UTF8
template0 postgres UTF8
template1 postgres UTF8
test001 postgres UTF8
(4 rows)
postgres=# \c test001
You are now connected to database "test001".
test001=# CREATE TABLE testing(
id INTEGER NOT NULL,
name TEXT NOT NULL,
PRIMARY KEY (id));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "testing_pkey" for table "testing"
CREATE TABLE
test001=# \d
List of relations
Schema Name Type Owner
--------+---------+-------+----------
public testing table postgres
(1 row)
test001=# \q
[postgres@servidor]#
Esto es todo por esta vez. Mucha mas información en los proximos articulos de esta serie.
Fuentes: postgresql.org / wikipedia.
Introducción a PostgreSQL - Configuración
En este segundo artículo de la serie vamos a hablar de como configurar PostgreSQL para sacarle el mayor provecho a esta base de datos en su version 8.2.x.
Como enseñamos en nuestro anterior artículo, PostgreSQL se puede empezar a utilizar sin necesidad de configurar, nada mas terminar de instalarlo y despues de inicializar nuestro "cluster". Pero si vamos a utilizar PostgreSQL para algo importante y con cierto volumen de datos y usuarios es imprescindible que lo configuremos para dicho trabajo.
No es la primera vez que algun asuario protesta o esta super preocupado de lo mal y lo lento que funciona su cluster de base de datos PostgreSQL en un servidor ultimo modelo con muchisima memoria. Normalmente el problema es que PostgreSQL no ha sido configurado para trabajar con el volumen de datos y usuarios con el que lo estamos usando. No es una gran ayuda tener un servidor con varios GBytes de memoria RAM si le hemos dicho a PostgreSQL, por ejemplo, que no utilice más de 32MBytes.
Tambien tenemos que decir que cualquier base de datos que se este usando activamente, no solo PostgreSQL, es un elemento dinamico y vivo en el que estamos cambiando los datos constantemente y donde el tamaño de los datos almacenados suele ir creciendo con el tiempo. Esto significa que una configuracion que funcione bien con ciertos valores hoy, puede que no funcione tan bien despues de un año de uso y que necesite ajustarse para que funcione optimalmente.
Configuración
El comportamiento de PostgreSQL en nuestro sistema se puede controlar con tres ficheros de configuración que se encuentran en el directorio de datos donde inicializamos nuestro cluster PostgreSQL (En nuestro caso /var/pgsql/data). Estos tres ficheros son:
* pg_hba.conf: Este fichero se utiliza para definir los diferentes tipos de accesos que un usuario tiene en el cluster.
* pg_ident.conf: Este fichero se utiliza para definir la información necesaria en el caso que utilicemos un acceso del tipo ident en pg_hba.conf .
* postgresql.conf: En este fichero podemos cambiar todos los parametros de configuracion que afectan al funcionamiento y al comportamiento de PostgreSQL en nuestra maquina.
Pasamos a continuación a explicar los cambios mas importantes que podemos hacer en algunos de estos ficheros.
pg_hba.conf
Este fichero se utiliza para definir como, donde y desde que sitio un usuario puede utilizar nuestro cluster PostgreSQL. Todas las lineas que empiezen con el caracter # se interpretan como comentarios. El resto debe de tener el siguiente formato:
[Tipo de conexion][database][usuario][IP][Netmask][Tipo de autentificacion][opciones]
Dependiendo del tipo de conexion y del tipo de autentificacion, [IP],[Netmask] y [opciones] pueden ser opcionales. Vamos a explicar un poco como definir las reglas de acceso. El tipo de conexion puede tener los siguientes valores, local, host, hostssl y hostnossl. El tipo de metodo puede tener los siguientes valores, trust, reject, md5, crypt, password, krb5, ident, pam o ldap
Una serie de ejemplos nos ayudaran a comprender mejor como podemos configurar diferentes accesos al cluster PostgreSQL.
Ejemplo 1 .- Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde el ordenador con IP 10.0.0.100, y metodo de autentificacion md5:
host test001 test 10.0.0.100 255.255.255.255 md5
Esta misma entrada se podria escribir tambien con la mascara de red en notacion CIDR:
host test001 test 10.0.0.100/32 md5
Ejemplo 2 .- Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde todos los ordenadores de la red 10.0.0.0, con mascara de red 255.255.255.0 (254 ordenadores en total) y metodo de autentificacion md5:
host test001 test 10.0.0.0 255.255.255.0 md5
Esta misma entrada se podria escribir tambien con la mascara de red en notacion CIDR:
host test001 test 10.0.0.0/24 md5
Ejemplo 3 .- Acceso por tcp/ip (red), encriptado, a todas las bases de datos de nuestro cluster, como usuario test desde el ordenador con IP 10.0.0.100, y el ordenador 10.1.1.100 y metodo de autentificacion md5 (necesitamos dos entradas en nuestro fichero pg_hba.conf:
hostssl all test 10.0.0.100 255.255.255.255 md5
hostssl all test 10.1.1.100 255.255.255.255 md5
Ejemplo 4.- Denegar el acceso a todos las bases de datos de nuestro cluster al usuario test, desde todos los ordenadores de la red 10.0.0.0/24 y dar accesso al resto del mundo con el metodo md5:
host all test 10.0.0.0/24 reject
host all all 0.0.0.0/0 md5
Asi podriamos seguir jugando con todas las posibilidades que nos brinda este fichero de configuracion. Por supuesto que las bases de datos y usuarios usados en este fichero tienen que existir en nuestro cluster para que todo funcione y algunos de los parametros solo se pueden usar si hemos compilado con las opciones pertinentes en el proceso de instalacion (por ejemplo, hostssl, pam, krb5)
Para poder en produccion los cambios en este fichero tendremos que decirle a PostgreSQL que vuelva a leerlo. Basta con un simple 'reload' (/usr/local/bin/pg_ctl -D /var/pgsql/data reload) desde la linea de comandos o con la funcion pg_reload_conf() como usuario postgres desde psql, el cliente PostgreSQL.
[postgres@servidor]# /usr/local/bin/psql
Welcome to psql 8.2.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
postgres=# SELECT pg_reload_conf();
pg_reload_conf
----------------
t
(1 row)
postgres=#
Para una documentacion detallada sobre el fichero pg_hba.con, pasaros por la seccion Chapter 20. Client Authentication de la documentacion oficial de PostgreSQL.
postgresql.conf
Los cambios que realicemos en este fichero afectaran a todas las bases de datos que tengamos definidas en nuestro cluster PostgreSQL. La mayoria de los cambios se pueden poner en produccion con un simple 'reload' (/usr/local/bin/pg_ctl -D /var/pgsql/data reload), otros cambios necesitan que arranquemos de nuevo nuestro cluster (/usr/local/bin/pg_ctl -D /var/pgsql/data restart).
Mas informacion sobre todos los parametros que podemos cambiar en este fichero, que afectan y como se pueden poner en produccion se puede encontrar en la seccion 17. Server Configuration de la documentacion oficial de PostgreSQL.
A continuacion vamos a ver los parametros mas importantes que deberiamos cambiar si empezamos a usar PostgreSQL para un uso serio y si queremos sacarle el maximo partido a nuestra maquina. Existen muchos mas parametros que se pueden y con el tiempo se deberan de ajustar, aqui nos vamos a centrar en los mas importantes y los cuales deberiamos cambiar antes de empezar a utilizar PostgreSQL de una manera seria.
max_connections: Numero maximo de clientes conectados a la vez a nuestras bases de datos. Deberiamos de incrementar este valor en proporcion al numero de clientes concurrentes en nuestro cluster PostgreSQL. Un buen valor para empezar es el 100:
max_connections = 100
shared_buffers: Este parametro es importantisimo y define el tamaño del buffer de memoria utilizado por PostgreSQL. No por aumentar este valor mucho tendremos mejor respuesta. En un servidor dedicado podemos empezar con un 25% del total de nuestra memoria. Nunca mas de 1/3 (33%) del total. Por ejemplo, en un servidor con 4Gbytes de memoria, podemos usar 1024MB como valor inicial.
shared_buffers = 1024MB
work_mem: Usada en operaciones que contengan ORDER BY, DISTINCT, joins, .... En un servidor dedicado podemos usar un 2-4% del total de nuestra memoria si tenemos solamente unas pocas sesiones (clientes) grandes. Como valor inicial podemos usar 8 Mbytes.
work_mem = 8MB
maintenance_work_mem: Usada en operaciones del tipo VACUUM, ANALYZE, CREATE INDEX, ALTER TABLE, ADD FOREIGN KEY. Su valor dependera mucho del tamaño de nuestras bases de datos. Por ejemplo, en un servidor con 4Gbytes de memoria, podemos usar 256MB como valor inicial.
maintenance_work_mem = 256MB
effective_cache_size: Parametro usado por el 'query planner' de nuestro motor de bases de datos para optimizar la lectura de datos. En un servidor dedicado podemos empezar con un 50% del total de nuestra memoria. Como maximo unos 2/3 (66%) del total. Por ejemplo, en un servidor con 4Gbytes de memoria, podemos usar 2048MB como valor inicial.
effective_cache_size = 2048MB
checkpoint_segments: Este parametro es muy importante en bases de datos con numerosas operaciones de escritura (insert,update,delete). Para empezar podemos empezar con un valor de 64. En grandes databases con muchos Gbytes de datos escritos podemos aumentar este valor hasta 128-256.
checkpoint_segments = 64
Es muy importante tener en cuenta que al aumentar los valores por defecto de muchos de estos parametros, tendremos que aumentar los valores por defecto de algunos parametros del kernel de nuestro sistema. Informacion detallada de como hacer esto se encuentra en la seccion 16.4. Managing Kernel Resources de la documentacion oficial de PostgreSQL.
En fin, esto es solo un aperitivo de lo que podemos hacer. Con la practica y la experiencia podremos y tendremos que ajustar otros muchos parametros. Pero esto sera materia de un proximo articulo.
Fuentes: postgresql.org.
Como enseñamos en nuestro anterior artículo, PostgreSQL se puede empezar a utilizar sin necesidad de configurar, nada mas terminar de instalarlo y despues de inicializar nuestro "cluster". Pero si vamos a utilizar PostgreSQL para algo importante y con cierto volumen de datos y usuarios es imprescindible que lo configuremos para dicho trabajo.
No es la primera vez que algun asuario protesta o esta super preocupado de lo mal y lo lento que funciona su cluster de base de datos PostgreSQL en un servidor ultimo modelo con muchisima memoria. Normalmente el problema es que PostgreSQL no ha sido configurado para trabajar con el volumen de datos y usuarios con el que lo estamos usando. No es una gran ayuda tener un servidor con varios GBytes de memoria RAM si le hemos dicho a PostgreSQL, por ejemplo, que no utilice más de 32MBytes.
Tambien tenemos que decir que cualquier base de datos que se este usando activamente, no solo PostgreSQL, es un elemento dinamico y vivo en el que estamos cambiando los datos constantemente y donde el tamaño de los datos almacenados suele ir creciendo con el tiempo. Esto significa que una configuracion que funcione bien con ciertos valores hoy, puede que no funcione tan bien despues de un año de uso y que necesite ajustarse para que funcione optimalmente.
Configuración
El comportamiento de PostgreSQL en nuestro sistema se puede controlar con tres ficheros de configuración que se encuentran en el directorio de datos donde inicializamos nuestro cluster PostgreSQL (En nuestro caso /var/pgsql/data). Estos tres ficheros son:
* pg_hba.conf: Este fichero se utiliza para definir los diferentes tipos de accesos que un usuario tiene en el cluster.
* pg_ident.conf: Este fichero se utiliza para definir la información necesaria en el caso que utilicemos un acceso del tipo ident en pg_hba.conf .
* postgresql.conf: En este fichero podemos cambiar todos los parametros de configuracion que afectan al funcionamiento y al comportamiento de PostgreSQL en nuestra maquina.
Pasamos a continuación a explicar los cambios mas importantes que podemos hacer en algunos de estos ficheros.
pg_hba.conf
Este fichero se utiliza para definir como, donde y desde que sitio un usuario puede utilizar nuestro cluster PostgreSQL. Todas las lineas que empiezen con el caracter # se interpretan como comentarios. El resto debe de tener el siguiente formato:
[Tipo de conexion][database][usuario][IP][Netmask][Tipo de autentificacion][opciones]
Dependiendo del tipo de conexion y del tipo de autentificacion, [IP],[Netmask] y [opciones] pueden ser opcionales. Vamos a explicar un poco como definir las reglas de acceso. El tipo de conexion puede tener los siguientes valores, local, host, hostssl y hostnossl. El tipo de metodo puede tener los siguientes valores, trust, reject, md5, crypt, password, krb5, ident, pam o ldap
Una serie de ejemplos nos ayudaran a comprender mejor como podemos configurar diferentes accesos al cluster PostgreSQL.
Ejemplo 1 .- Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde el ordenador con IP 10.0.0.100, y metodo de autentificacion md5:
host test001 test 10.0.0.100 255.255.255.255 md5
Esta misma entrada se podria escribir tambien con la mascara de red en notacion CIDR:
host test001 test 10.0.0.100/32 md5
Ejemplo 2 .- Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde todos los ordenadores de la red 10.0.0.0, con mascara de red 255.255.255.0 (254 ordenadores en total) y metodo de autentificacion md5:
host test001 test 10.0.0.0 255.255.255.0 md5
Esta misma entrada se podria escribir tambien con la mascara de red en notacion CIDR:
host test001 test 10.0.0.0/24 md5
Ejemplo 3 .- Acceso por tcp/ip (red), encriptado, a todas las bases de datos de nuestro cluster, como usuario test desde el ordenador con IP 10.0.0.100, y el ordenador 10.1.1.100 y metodo de autentificacion md5 (necesitamos dos entradas en nuestro fichero pg_hba.conf:
hostssl all test 10.0.0.100 255.255.255.255 md5
hostssl all test 10.1.1.100 255.255.255.255 md5
Ejemplo 4.- Denegar el acceso a todos las bases de datos de nuestro cluster al usuario test, desde todos los ordenadores de la red 10.0.0.0/24 y dar accesso al resto del mundo con el metodo md5:
host all test 10.0.0.0/24 reject
host all all 0.0.0.0/0 md5
Asi podriamos seguir jugando con todas las posibilidades que nos brinda este fichero de configuracion. Por supuesto que las bases de datos y usuarios usados en este fichero tienen que existir en nuestro cluster para que todo funcione y algunos de los parametros solo se pueden usar si hemos compilado con las opciones pertinentes en el proceso de instalacion (por ejemplo, hostssl, pam, krb5)
Para poder en produccion los cambios en este fichero tendremos que decirle a PostgreSQL que vuelva a leerlo. Basta con un simple 'reload' (/usr/local/bin/pg_ctl -D /var/pgsql/data reload) desde la linea de comandos o con la funcion pg_reload_conf() como usuario postgres desde psql, el cliente PostgreSQL.
[postgres@servidor]# /usr/local/bin/psql
Welcome to psql 8.2.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
postgres=# SELECT pg_reload_conf();
pg_reload_conf
----------------
t
(1 row)
postgres=#
Para una documentacion detallada sobre el fichero pg_hba.con, pasaros por la seccion Chapter 20. Client Authentication de la documentacion oficial de PostgreSQL.
postgresql.conf
Los cambios que realicemos en este fichero afectaran a todas las bases de datos que tengamos definidas en nuestro cluster PostgreSQL. La mayoria de los cambios se pueden poner en produccion con un simple 'reload' (/usr/local/bin/pg_ctl -D /var/pgsql/data reload), otros cambios necesitan que arranquemos de nuevo nuestro cluster (/usr/local/bin/pg_ctl -D /var/pgsql/data restart).
Mas informacion sobre todos los parametros que podemos cambiar en este fichero, que afectan y como se pueden poner en produccion se puede encontrar en la seccion 17. Server Configuration de la documentacion oficial de PostgreSQL.
A continuacion vamos a ver los parametros mas importantes que deberiamos cambiar si empezamos a usar PostgreSQL para un uso serio y si queremos sacarle el maximo partido a nuestra maquina. Existen muchos mas parametros que se pueden y con el tiempo se deberan de ajustar, aqui nos vamos a centrar en los mas importantes y los cuales deberiamos cambiar antes de empezar a utilizar PostgreSQL de una manera seria.
max_connections: Numero maximo de clientes conectados a la vez a nuestras bases de datos. Deberiamos de incrementar este valor en proporcion al numero de clientes concurrentes en nuestro cluster PostgreSQL. Un buen valor para empezar es el 100:
max_connections = 100
shared_buffers: Este parametro es importantisimo y define el tamaño del buffer de memoria utilizado por PostgreSQL. No por aumentar este valor mucho tendremos mejor respuesta. En un servidor dedicado podemos empezar con un 25% del total de nuestra memoria. Nunca mas de 1/3 (33%) del total. Por ejemplo, en un servidor con 4Gbytes de memoria, podemos usar 1024MB como valor inicial.
shared_buffers = 1024MB
work_mem: Usada en operaciones que contengan ORDER BY, DISTINCT, joins, .... En un servidor dedicado podemos usar un 2-4% del total de nuestra memoria si tenemos solamente unas pocas sesiones (clientes) grandes. Como valor inicial podemos usar 8 Mbytes.
work_mem = 8MB
maintenance_work_mem: Usada en operaciones del tipo VACUUM, ANALYZE, CREATE INDEX, ALTER TABLE, ADD FOREIGN KEY. Su valor dependera mucho del tamaño de nuestras bases de datos. Por ejemplo, en un servidor con 4Gbytes de memoria, podemos usar 256MB como valor inicial.
maintenance_work_mem = 256MB
effective_cache_size: Parametro usado por el 'query planner' de nuestro motor de bases de datos para optimizar la lectura de datos. En un servidor dedicado podemos empezar con un 50% del total de nuestra memoria. Como maximo unos 2/3 (66%) del total. Por ejemplo, en un servidor con 4Gbytes de memoria, podemos usar 2048MB como valor inicial.
effective_cache_size = 2048MB
checkpoint_segments: Este parametro es muy importante en bases de datos con numerosas operaciones de escritura (insert,update,delete). Para empezar podemos empezar con un valor de 64. En grandes databases con muchos Gbytes de datos escritos podemos aumentar este valor hasta 128-256.
checkpoint_segments = 64
Es muy importante tener en cuenta que al aumentar los valores por defecto de muchos de estos parametros, tendremos que aumentar los valores por defecto de algunos parametros del kernel de nuestro sistema. Informacion detallada de como hacer esto se encuentra en la seccion 16.4. Managing Kernel Resources de la documentacion oficial de PostgreSQL.
En fin, esto es solo un aperitivo de lo que podemos hacer. Con la practica y la experiencia podremos y tendremos que ajustar otros muchos parametros. Pero esto sera materia de un proximo articulo.
Fuentes: postgresql.org.
Emulador de shell unix (linux) online
Estrictamente, no es exactamente una shell de unix ni de linux. Pero podemos hacer muchísimas cosas propias de una linea de comandos de sistemas unix. Hay un muchos comandos que se pueden utilizar: ps, vi grep,sed,cat,tail,ls. Cuando solicita login y password, pulsar intro. Curioso
Ingresa al emulador Aqui
Ingresa al emulador Aqui
Aplicaciones Inalámbricas un Modelo Nuevo
Muchos sitios en Internet ya se encuentran habilitados para enviar información hacia aparatos inalámbricos, una descripción de esta modalidad se describe en Aplicaciones Inalámbricas (WAP-WML) , sin embargo, la principal carencia de esta Tecnología (WAP-WML) reside en la Interfase Gráfica capaz de observarse en los dispositivos inalámbricos (Teléfonos Celulares, PDA's, etc).
Ante este problema han surgido nuevos mecanismos para enviar contenido hacia medios inalámbricos.
J2ME ("Java 2 Micro Edition")
J2ME viene a formar el ultimo "Suite" desarrollado por Sun Microsystems , al lado del J2SE ("Java 2 Standard Edition") y J2EE ("Java 2 Enterprise Edition") el cual esta enfocado hacia aplicaciones inalámbricas.
Varias características diferencian a J2ME de otras tecnologías inalámbricas :
La primera y más obvia, es la integración transparente con otras Tecnologías Java .
Otra capacidad reside en la posibilidad de ejecutar aplicaciones altamente dinámicas en el dispositivo inalámbrico, en este sentido, es posible ejecutar/guardar programas altamente gráficos/vídeos a través de una conexión en Internet, caso no posible con WAP/WML .
Finalmente la Interfase Gráfica en general se ve ampliamente superada a diferencia de aplicaciones WAP/WML.
BREW ("Binary Runtime Enviorment for Wireless")
BREW ("Binary Runtime Environment for Wireless") es una creación de la empresa Qualcomm que intenta ofrecer la misma solución al mercado inalámbrico, el generar aplicaciones dinámicas altamente gráficas en el Cliente (Teléfono Celular), esto a diferencia de WAP-WML donde un Servidor de Páginas genera un contenido muy restringido para el Cliente (Teléfono Celular).
A diferencia de J2ME("Java 2 Micro Edition"), BREW ("Binary Runtime Environment for Wireless") es una Tecnología basada en los lenguajes C y C++, esto ofrece una alternativa para aquellos que no están especializados en el mundo Java .
Proveedores de Servicio y Aparatos Inalámbricos.
Para que cualquier Tecnología sea exitosa se requiere del apoyo de diversos proveedores, J2ME así como BREW no son la excepción.
Primeramente es necesario que el dispositivo inalámbrico sea capaz de ejecutar este tipo de Aplicaciones así como el proveedor de servicios, esto trae consigo otras consideraciones ya que es posible que el usuario final ni siquiera sea capaz de observar la aplicación correctamente.
Actualmente una de las empresas lideres en ofrecer servicios en J2ME es Nextel , mientras que para BREW es su mismo creador Qualcomm una empresa ya especializada en este ramo.
Ante este problema han surgido nuevos mecanismos para enviar contenido hacia medios inalámbricos.
J2ME ("Java 2 Micro Edition")
J2ME viene a formar el ultimo "Suite" desarrollado por Sun Microsystems , al lado del J2SE ("Java 2 Standard Edition") y J2EE ("Java 2 Enterprise Edition") el cual esta enfocado hacia aplicaciones inalámbricas.
Varias características diferencian a J2ME de otras tecnologías inalámbricas :
La primera y más obvia, es la integración transparente con otras Tecnologías Java .
Otra capacidad reside en la posibilidad de ejecutar aplicaciones altamente dinámicas en el dispositivo inalámbrico, en este sentido, es posible ejecutar/guardar programas altamente gráficos/vídeos a través de una conexión en Internet, caso no posible con WAP/WML .
Finalmente la Interfase Gráfica en general se ve ampliamente superada a diferencia de aplicaciones WAP/WML.
BREW ("Binary Runtime Enviorment for Wireless")
BREW ("Binary Runtime Environment for Wireless") es una creación de la empresa Qualcomm que intenta ofrecer la misma solución al mercado inalámbrico, el generar aplicaciones dinámicas altamente gráficas en el Cliente (Teléfono Celular), esto a diferencia de WAP-WML donde un Servidor de Páginas genera un contenido muy restringido para el Cliente (Teléfono Celular).
A diferencia de J2ME("Java 2 Micro Edition"), BREW ("Binary Runtime Environment for Wireless") es una Tecnología basada en los lenguajes C y C++, esto ofrece una alternativa para aquellos que no están especializados en el mundo Java .
Proveedores de Servicio y Aparatos Inalámbricos.
Para que cualquier Tecnología sea exitosa se requiere del apoyo de diversos proveedores, J2ME así como BREW no son la excepción.
Primeramente es necesario que el dispositivo inalámbrico sea capaz de ejecutar este tipo de Aplicaciones así como el proveedor de servicios, esto trae consigo otras consideraciones ya que es posible que el usuario final ni siquiera sea capaz de observar la aplicación correctamente.
Actualmente una de las empresas lideres en ofrecer servicios en J2ME es Nextel , mientras que para BREW es su mismo creador Qualcomm una empresa ya especializada en este ramo.
jueves, 15 de mayo de 2008
FTP
El FTP solía ser el protocolo más usado en Internet por el tráfico puro de datos hasta que fue sobrepasado por el HTTP hace unos años (sí, una vez hubo un Internet libre de WWW). El FTP hace una cosa, y lo hace bien, transferir ficheros entre sistemas. El protocolo en sí mismo es inseguro, contraseñas, datos, etc, se transfieren en texto claro y pueden ser esnifados con facilidad, sin embargo la mayoría del uso del ftp es ‘anónimo’, de modo que no es un gran problema. Uno de los principales problemas con que se suelen encontrar los sitios de ftp son los permisos incorrectos en directorios que permiten a la gente utilizar el sitio para distribuir sus propios datos (por lo general material con copyrights). Al igual que con telnet, se debería utilizar una cuenta para hacer ftp que no se utilizara para hacer trabajos administrativos, puesto que la contraseña viaja por la red en texto claro.
En general, los problemas con el ftp incluyen:
Autentificación en texto claro, nombre de usuario y contraseña.
Texto en claro en todos los comandos.
Ataques de adivinación de contraseñas.
Configuración inadecuada del servidor y el consiguiente abuso de servidores.
Todavía existen varios desagradables ataques de Negación de Servicio en algunos servidores de ftp.
Las versiones más antiguas de WU-FTPD y sus derivados tienen ataques de root.
Asegurar FTP no es demasiado difícil, entre los cortafuegos y los TCP_WRAPPERS se puede restringir bastante bien el acceso basado en la dirección IP / hostname. Además, la mayoría de los servidores ftp se ejecutan bajo chroot por defecto para cualquiera con acceso anónimo, o en una cuenta definida como invitado. Con un poco de trabajo, se puede configurar a los usuarios que están haciendo ftp para hacer chroot su directorio personal, o cualquier otra cosa apropiada. También se pueden ejecutar servidores de ftp que cifren los datos (utilizando cosas como SSL/etc.) sin embargo eso significa que tus clientes ftp deben hablar el protocolo de cifrado, y ello no siempre es práctico. También asegúrate de que no se tienen directorios de acceso público en el servidor de ftp que sean a la vez legibles y que se puedan escribir, o si no la gente los explotará para distribuir su propio software (generalmente warez o porno).
Un ejemplo de reglas de filtrado para el cortafuegos:
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 21
ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 21
ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 21
o
ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 21
ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 21
ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 21
Un ejemplo de lo mismo utilizando TCP_WRAPPERS:
En /etc/hosts.allow
in.ftpd: 10.0.0.0/255.0.0.0, un.host.fiable
Y en /etc/hosts.deny
in.ftpd: 0.0.0.0/0.0.0.0
Existen diferentes alternativas cifradas a ftp como se mencionó más arriba, SSLeay FTPD y otras utilidades de terceros. puesto que la mayoría de cuentas ftp no se utilizan como cuentas de administración (contraseñas en texto claro, ya has sido advertido), y es de esperar que se ejecuten con chroot, el riesgo de seguridad se minimiza. Ahora que tenemos cubiertas todas las partes de ftp basadas en red, vamos con la forma de asegurar cuentas de usuarios y el entorno.
WU-FTPD
No recomendaría el uso del WU-FTPD, puesto que tiene muchos problemas de seguridad, y bastantes vendedores de Linux no utilizan WU-FTPD en sus propios servidores de ftp. Recomendaría encarecidamente ProFTPD, que está disponible gratuitamente y se desarrolla en la siguiente sección.
Uno de los principales mecanismos de seguridad de WU-FTPD es el uso de chroot. Por ejemplo: por defecto toda la gente haciendo login de forma anónima tiene /home/ftp/ como el directorio raíz. No pueden salir de aquí y, digamos, mirar el contenido de /home/ o /etc/. Lo mismo se aplica a grupos de usuarios y/o individuos, por ejemplo, se podría configurar a todos los usuarios para que fuesen hechos chroot a /home/ cuando hacen el ftp, o en casos extremos de privacidad de usuarios (digamos un servidor de www albergando múltiples dominios) configurar cada usuario con chroot a su propio directorio personal. Esto se hace mediante el uso de /etc/ftpaccess y /etc/passwd (haciendo man ftpaccess se obtienen toda la información). Daré unos cuantos ejemplos de lo que es necesario hacer para llevarlo a cabo, puesto que al principio puede resultar algo confuso. ftpd también verifica /etc/ftpusers y si el usuario que está intentando hacer login aparece listado en ese fichero (como debería estarlo el root) no le dejará acceder vía ftp.
Hacer chroot a usuarios a medida que van haciendo login en el servidor de ftp es bastante simple, pero está pobremente documentado. La comprobación del servidor de ftp de /etc/ftpaccess en busca de "guestgroup"’s, que son simplemente "guestgroup cualquier-grupo-del-sistema" p. ej. "guestgroup usuarios". El nombre de grupo tiene que estar definido en /etc/group y tener añadidos miembros. Es necesario editar la línea de su fichero de contraseñas, de forma que el servidor de ftp sepa dónde volcarlos. Y puesto que ahora están hechos chroot a ese directorio del sistema, no tienen acceso a /lib, etc, así que hay que copiar ciertos ficheros a sus directorios para que cosas como "ls" funcionen correctamente (siempre un toque elegante).
Configurar un usuario (felipefroilan) de forma que pueda entrar por ftp y acabe siendo hecho chroot a su directorio personal (porque sigue amenazando al administrador con llevarle a cazar gamusinos). Además de esto, felipefroilan puede entrar por telnet y cambiar su contraseña, pero nada más, porque sigue intentando ejecutar bots de irc. El sistema en que está utiliza contraseñas con shadow, por eso hay una ‘x’ en el campo de contraseñas de felipefroilan.
Lo primero de todo es que felipefroilan necesita tener una cuenta correctamente configurada en /etc/passwd:
felipefroilan:x:500:Felipe Juan Froilan:/home/felipefroilan/./:/usr/bin/passwd
Lo que significa que el servidor de ftp hará un chroot de felipefroilan y luego le hará un chdir en lo que ahora se conoce como / (/home/felipefroilan para el resto de nosotros). La página del manual de ftpaccess cubre bien todo esto, y por supuesto que /usr/sbin/passwd tiene que estar listado en /etc/shells.
Segundo, para que el servidor de ftp sepa que se le está haciendo chroot, tiene que ser miembro de un grupo (usuariosmalos, genteftp, etc) que venga definido en /etc/group. Y después ese grupo tiene que aparecer listado en /etc/ftpaccess.
Ahora hay que copiar algunas librerías y binarios en la "cárcel" chroot, si no "felipefroilan" no va a poder hacer demasiadas cosas una vez que haya entrado por ftp. Los ficheros necesarios están disponibles como paquete (normalmente llamado "anonftp"), una vez que esté instalado, los ficheros se copiarán a /home/ftp/, te darás cuenta de que hay un /etc/passwd, que sólo se usa para mapear UID’s a nombres de usuarios, si quieres que felipefroilan vea su nombre de usuario y no su UID, añade una línea para él (p. ej., copia esta línea desde el /etc/passwd real por esta otra). Lo mismo se aplica al fichero de grupos.
sin "felipefroilan:*:500:500:::" en /home/felipefroilan/etc/passwd:
drwxr-xr-x 2 500 500 1024 Jul 14 20:46 felipefroilan
y con la línea añadida a /home/felipefroilan/etc/passwd:
drwxr-xr-x 2 felipefroilan 500 1024 Jul 14 20:46 felipefroilan
y con una línea para el grupo de felipefroilan añadida a /home/felipefroilan/etc/group:
drwxr-xr-x 2 felipefroilan felipefroilan 1024 Jul 14 20:46 felipefroilan
Ahora felipefroilan puede hacer un ftp al sistema, subir y descargar ficheros desde el directorio /home/felipefroilan, cambiar él mimo su contraseña y no dañar el sistema, ni descargar el fichero de contraseñas u otro tipo de incordios.
El FTP también es un protocolo bastante especial, pues los clientes se conectan al puerto 21 (por lo general) del servidor de ftp, y luego, en el puerto 20 del servidor de ftp se conecta al cliente, y es sobre esta conexión donde viajan los datos reales. Lo cual significa que el puerto 20 tiene que hacer conexiones externas. Hay que tener esto en cuenta cuando se configure un cortafuegos, ya sea para proteger servidores ftp o clientes utilizando ftp. De igual forma, existe un ftp "pasivo", y generalmente se suele utilizar por visores www/etc, lo cual significa conexiones entrantes al servidor en puertos altos (en lugar de utilizar el 20, se ponen de acuerdo en algún otro). Si se pretende tener un servidor ftp público que SÓLO vaya a servir ftp, y nada más, colócalo preferiblemente fuera de nuestra LAN interna (ver Practical Unix and Internet Security para discusiones del concepto ‘DMZ’). Se puede conseguir WU-FTPD de ftp://ftp.wu-ftpd.org/∞
ProFTPD
ProFTPD es un servidor con licencia GPL que se ejecuta en una variedad de plataformas UNIX. Soporta nuevas características como ftp virtual, configuración por directorio (utilizando ficheros .ftpaccess, similares a los ficheros .htaccess de Apache), soporte para cuentas que han expirado y más. También soporta características bastante útiles como la limitación de descargas y controles de seguridad más férreos que WU-FTPD. Lo recomendaría encarecidamente por encima de otros servidores de FTP para UNIX gratuitos.
El fichero de configuración principal de ProFTPD es /etc/proftpd.conf, tiene un estilo de configuración Apachesca que me gusta mucho. ProFTPD se puede ejecutar desde inetd (y hacer uso de TCP_WRAPPERS) o se puede ejecutar como servidor autónomo. También soporta ficheros de configuración por directorio para limitar el acceso, etc. ProFTPD también soporta ftp virtual (aunque al contrario que con un servidor virtual de www, son necesarias IPs extra) y se puede configurar cada sitio de forma diferente (diferente acceso anónimo, si es que lo hay, y más cosas de entre esas líneas). El fichero general proftpd.conf suele tener una sección que cubre los parámetros globales (inetd o autónomo, número máximo de procesos a ejecutar, como quien se ejecuta, etc.), seguido de un fichero de configuración por defecto, seguido de una configuración específica del sitio (sitios virtuales). En un servidor haciendo hosting virtual probablemente sea una buena idea desactivar "DefaultServer", de modo que cualquier cliente que haga ftp sin ningún objetivo sea denegada, en lugar de volcada dentro del sitio por defecto.
Una configuración de ejemplo de un servidor ProFTPD ejecutándose desde inetd sin acceso anónimo:
ServerName "Instalación por defecto de ProFTPD"
ServerType inetd
DefaultServer on
Port 21
Umask 022
MaxInstances 30
User nobody
Group nobody
AllowOverWrite on
Digamos que, al igual que yo, eres paranoico y quieres controlar el acceso al servidor de ftp mediante direcciones IP, nombres de hosts y nombres de dominio (aunque recomendaría confiar sólo en las IP’s). Esto se puede conseguir mediante reglas del cortafuegos, pero eso acaba ralentizando la máquina (especialmente si se añaden multitud de reglas, como tiende a ocurrir). Se puede utilizar TCP_WRAPPERS , pero no sería posible limitar selectivamente el acceso a sitios virtuales, sitios anónimos, sólo al servidor en sí mismo. O se puede hacer en el fichero proftpd.conf utilizando la directiva "".
El siguiente ejemplo limitará el acceso a 10.1.*.* y 1.2.3.4, a cualquier otra máquina se le denegará el acceso.
Order Allow, Deny
Allow from 10.1., 1.2.3.4
Deny from all
Si se coloca esto dentro de las directivas "" o "", se aplica sólo a ese sitio virtual o configuración anónima, si se coloca en la directiva "" se aplicará a todas las secciones "" y "", y si se coloca en la configuración del servidor (p. ej. con "ServerName" y elementos relacionados) se comportará como lo haría TCP_WRAPPERS, cualquiera desde 10.1.*.* o desde 1.2.3.4 impacta cuando se intenta conectar al puerto 21, al contrario que si simplemente le negase el login si no está en la sección "", "" o "".
Si se quiere añadir más accesos anónimos, tan sólo añadir:
User ftp
Group ftp
RequireValidShell off
UserAlias anonymous ftp
MaxClients 10
DisplayLogin bienvenido.msg
DisplayFirstChdir .message
DenyAll
Esto asignaría el directorio personal de los usuarios "ftp" (suponiendo que la configuración normal de "~ftp" probablemente fuese /home/ftp) como el directorio raíz anónimo, cuando la gente hiciese login anónimo, el ProFTPD se ejecutaría como el usuario "ftp" y el grupo "ftp" (al contrario que si se hiciera login como un usuario normal), y los logins anónimos se limitarían a 10. De igual forma, el fichero /home/ftp/bienvenido.msg se mostraría cuando hiciesen ftp los usuarios anónimos, y cualquier directorio con un fichero .message que contuviera texto, el cual se mostraría al cambiar a tal directorio. El "" se ocupa de /home/ftp/*, y después deniega el acceso de escritura a todos, lo cual quiere decir que nadie puede subir ficheros. Si se quisiera añadir in directorio entrante, simplemente se añadiría lo siguiente después de las directivas "":
AllowAll
DenyAll
Lo cual le permitiría a la gente escribir ficheros en /home/ftp/incoming, pero no leerlos (es decir, descargarlos). Como se puede ver, ProFTPD es muy flexible, lo cual da como resultado mayores requerimientos de potencia que el WU-FTPD, pero definitivamente merece la pena por el control añadido. ProFTPD y su documentación se pueden conseguir en: http://www.protftpd.org/∞
proftpd-ldap
El proftpd-ldap te permite hacer consultas por contraseñas utilizando un directorio LDAP, se puede descargar de: http://horde.net/~jwm/software/proftpd-ldap/∞
NcFTPD
El NcFTPD es un servidor ftp de gran volumen, sin embargo sólo se encuentra disponible para uso personal o educativo. Se puede conseguir en: http://www.ncftpd.com/ncftpd∞.
BSD ftpd
El servidor ftp de BSD (ftpd) también se ha transportado a Linux, de modo que si necesitas ejecutarlo, se puede descargar de: ftp://quatramaran.ens.fr/pub/madore/ftpd-BSD/∞
Muddleftpd
El Muddleftpd is un pequeño servidor de ftp. Se puede conseguir en: http://www.computing.edu.au/~kuiperba/muddleftpd/∞.
Troll ftpd
El Troll ftpd es un servidor ftp extremadamente pequeño y relativamente seguro. No puede ejecutar programas externos, y es bastante fácil de configurar. Se puede conseguir en: http://www.troll.no/freebies/ftpd.html∞.
BetaFTPD
El BetaFTPD es un pequeño servidor ftp de un solo hilo. Se puede conseguir en: http://members.xoom.com/_XOOM/sneeze/betaftpd.html∞.
FTP - SSL
Otro reemplazo de tu ftpd favorito (probablemente WU-FTPD), también disponible como un conjunto de parches para el WU-FTPD. Es altamente apropiado, puesto que la mayoría de los servidores tienen muchos usuarios que necesitan acceso ftp. El tarball está disponible en: ftp://ftp.uni-mainz.de/pub/internet/security/ssl/∞, y como paquetes RPM en ftp://ftp.replay.com/pub/replay/linux/redhat/∞
FTP - SRP
El SRP también se puede utilizar para cifrar la porción nombre de usuario / contraseña de tu sesión ftp, o de la sesión completa. Se puede conseguir en: http://srp.arcot.com/srp/∞
En general, los problemas con el ftp incluyen:
Autentificación en texto claro, nombre de usuario y contraseña.
Texto en claro en todos los comandos.
Ataques de adivinación de contraseñas.
Configuración inadecuada del servidor y el consiguiente abuso de servidores.
Todavía existen varios desagradables ataques de Negación de Servicio en algunos servidores de ftp.
Las versiones más antiguas de WU-FTPD y sus derivados tienen ataques de root.
Asegurar FTP no es demasiado difícil, entre los cortafuegos y los TCP_WRAPPERS se puede restringir bastante bien el acceso basado en la dirección IP / hostname. Además, la mayoría de los servidores ftp se ejecutan bajo chroot por defecto para cualquiera con acceso anónimo, o en una cuenta definida como invitado. Con un poco de trabajo, se puede configurar a los usuarios que están haciendo ftp para hacer chroot su directorio personal, o cualquier otra cosa apropiada. También se pueden ejecutar servidores de ftp que cifren los datos (utilizando cosas como SSL/etc.) sin embargo eso significa que tus clientes ftp deben hablar el protocolo de cifrado, y ello no siempre es práctico. También asegúrate de que no se tienen directorios de acceso público en el servidor de ftp que sean a la vez legibles y que se puedan escribir, o si no la gente los explotará para distribuir su propio software (generalmente warez o porno).
Un ejemplo de reglas de filtrado para el cortafuegos:
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 21
ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 21
ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 21
o
ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 21
ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 21
ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 21
Un ejemplo de lo mismo utilizando TCP_WRAPPERS:
En /etc/hosts.allow
in.ftpd: 10.0.0.0/255.0.0.0, un.host.fiable
Y en /etc/hosts.deny
in.ftpd: 0.0.0.0/0.0.0.0
Existen diferentes alternativas cifradas a ftp como se mencionó más arriba, SSLeay FTPD y otras utilidades de terceros. puesto que la mayoría de cuentas ftp no se utilizan como cuentas de administración (contraseñas en texto claro, ya has sido advertido), y es de esperar que se ejecuten con chroot, el riesgo de seguridad se minimiza. Ahora que tenemos cubiertas todas las partes de ftp basadas en red, vamos con la forma de asegurar cuentas de usuarios y el entorno.
WU-FTPD
No recomendaría el uso del WU-FTPD, puesto que tiene muchos problemas de seguridad, y bastantes vendedores de Linux no utilizan WU-FTPD en sus propios servidores de ftp. Recomendaría encarecidamente ProFTPD, que está disponible gratuitamente y se desarrolla en la siguiente sección.
Uno de los principales mecanismos de seguridad de WU-FTPD es el uso de chroot. Por ejemplo: por defecto toda la gente haciendo login de forma anónima tiene /home/ftp/ como el directorio raíz. No pueden salir de aquí y, digamos, mirar el contenido de /home/ o /etc/. Lo mismo se aplica a grupos de usuarios y/o individuos, por ejemplo, se podría configurar a todos los usuarios para que fuesen hechos chroot a /home/ cuando hacen el ftp, o en casos extremos de privacidad de usuarios (digamos un servidor de www albergando múltiples dominios) configurar cada usuario con chroot a su propio directorio personal. Esto se hace mediante el uso de /etc/ftpaccess y /etc/passwd (haciendo man ftpaccess se obtienen toda la información). Daré unos cuantos ejemplos de lo que es necesario hacer para llevarlo a cabo, puesto que al principio puede resultar algo confuso. ftpd también verifica /etc/ftpusers y si el usuario que está intentando hacer login aparece listado en ese fichero (como debería estarlo el root) no le dejará acceder vía ftp.
Hacer chroot a usuarios a medida que van haciendo login en el servidor de ftp es bastante simple, pero está pobremente documentado. La comprobación del servidor de ftp de /etc/ftpaccess en busca de "guestgroup"’s, que son simplemente "guestgroup cualquier-grupo-del-sistema" p. ej. "guestgroup usuarios". El nombre de grupo tiene que estar definido en /etc/group y tener añadidos miembros. Es necesario editar la línea de su fichero de contraseñas, de forma que el servidor de ftp sepa dónde volcarlos. Y puesto que ahora están hechos chroot a ese directorio del sistema, no tienen acceso a /lib, etc, así que hay que copiar ciertos ficheros a sus directorios para que cosas como "ls" funcionen correctamente (siempre un toque elegante).
Configurar un usuario (felipefroilan) de forma que pueda entrar por ftp y acabe siendo hecho chroot a su directorio personal (porque sigue amenazando al administrador con llevarle a cazar gamusinos). Además de esto, felipefroilan puede entrar por telnet y cambiar su contraseña, pero nada más, porque sigue intentando ejecutar bots de irc. El sistema en que está utiliza contraseñas con shadow, por eso hay una ‘x’ en el campo de contraseñas de felipefroilan.
Lo primero de todo es que felipefroilan necesita tener una cuenta correctamente configurada en /etc/passwd:
felipefroilan:x:500:Felipe Juan Froilan:/home/felipefroilan/./:/usr/bin/passwd
Lo que significa que el servidor de ftp hará un chroot de felipefroilan y luego le hará un chdir en lo que ahora se conoce como / (/home/felipefroilan para el resto de nosotros). La página del manual de ftpaccess cubre bien todo esto, y por supuesto que /usr/sbin/passwd tiene que estar listado en /etc/shells.
Segundo, para que el servidor de ftp sepa que se le está haciendo chroot, tiene que ser miembro de un grupo (usuariosmalos, genteftp, etc) que venga definido en /etc/group. Y después ese grupo tiene que aparecer listado en /etc/ftpaccess.
Ahora hay que copiar algunas librerías y binarios en la "cárcel" chroot, si no "felipefroilan" no va a poder hacer demasiadas cosas una vez que haya entrado por ftp. Los ficheros necesarios están disponibles como paquete (normalmente llamado "anonftp"), una vez que esté instalado, los ficheros se copiarán a /home/ftp/, te darás cuenta de que hay un /etc/passwd, que sólo se usa para mapear UID’s a nombres de usuarios, si quieres que felipefroilan vea su nombre de usuario y no su UID, añade una línea para él (p. ej., copia esta línea desde el /etc/passwd real por esta otra). Lo mismo se aplica al fichero de grupos.
sin "felipefroilan:*:500:500:::" en /home/felipefroilan/etc/passwd:
drwxr-xr-x 2 500 500 1024 Jul 14 20:46 felipefroilan
y con la línea añadida a /home/felipefroilan/etc/passwd:
drwxr-xr-x 2 felipefroilan 500 1024 Jul 14 20:46 felipefroilan
y con una línea para el grupo de felipefroilan añadida a /home/felipefroilan/etc/group:
drwxr-xr-x 2 felipefroilan felipefroilan 1024 Jul 14 20:46 felipefroilan
Ahora felipefroilan puede hacer un ftp al sistema, subir y descargar ficheros desde el directorio /home/felipefroilan, cambiar él mimo su contraseña y no dañar el sistema, ni descargar el fichero de contraseñas u otro tipo de incordios.
El FTP también es un protocolo bastante especial, pues los clientes se conectan al puerto 21 (por lo general) del servidor de ftp, y luego, en el puerto 20 del servidor de ftp se conecta al cliente, y es sobre esta conexión donde viajan los datos reales. Lo cual significa que el puerto 20 tiene que hacer conexiones externas. Hay que tener esto en cuenta cuando se configure un cortafuegos, ya sea para proteger servidores ftp o clientes utilizando ftp. De igual forma, existe un ftp "pasivo", y generalmente se suele utilizar por visores www/etc, lo cual significa conexiones entrantes al servidor en puertos altos (en lugar de utilizar el 20, se ponen de acuerdo en algún otro). Si se pretende tener un servidor ftp público que SÓLO vaya a servir ftp, y nada más, colócalo preferiblemente fuera de nuestra LAN interna (ver Practical Unix and Internet Security para discusiones del concepto ‘DMZ’). Se puede conseguir WU-FTPD de ftp://ftp.wu-ftpd.org/∞
ProFTPD
ProFTPD es un servidor con licencia GPL que se ejecuta en una variedad de plataformas UNIX. Soporta nuevas características como ftp virtual, configuración por directorio (utilizando ficheros .ftpaccess, similares a los ficheros .htaccess de Apache), soporte para cuentas que han expirado y más. También soporta características bastante útiles como la limitación de descargas y controles de seguridad más férreos que WU-FTPD. Lo recomendaría encarecidamente por encima de otros servidores de FTP para UNIX gratuitos.
El fichero de configuración principal de ProFTPD es /etc/proftpd.conf, tiene un estilo de configuración Apachesca que me gusta mucho. ProFTPD se puede ejecutar desde inetd (y hacer uso de TCP_WRAPPERS) o se puede ejecutar como servidor autónomo. También soporta ficheros de configuración por directorio para limitar el acceso, etc. ProFTPD también soporta ftp virtual (aunque al contrario que con un servidor virtual de www, son necesarias IPs extra) y se puede configurar cada sitio de forma diferente (diferente acceso anónimo, si es que lo hay, y más cosas de entre esas líneas). El fichero general proftpd.conf suele tener una sección que cubre los parámetros globales (inetd o autónomo, número máximo de procesos a ejecutar, como quien se ejecuta, etc.), seguido de un fichero de configuración por defecto, seguido de una configuración específica del sitio (sitios virtuales). En un servidor haciendo hosting virtual probablemente sea una buena idea desactivar "DefaultServer", de modo que cualquier cliente que haga ftp sin ningún objetivo sea denegada, en lugar de volcada dentro del sitio por defecto.
Una configuración de ejemplo de un servidor ProFTPD ejecutándose desde inetd sin acceso anónimo:
ServerName "Instalación por defecto de ProFTPD"
ServerType inetd
DefaultServer on
Port 21
Umask 022
MaxInstances 30
User nobody
Group nobody
AllowOverWrite on
Digamos que, al igual que yo, eres paranoico y quieres controlar el acceso al servidor de ftp mediante direcciones IP, nombres de hosts y nombres de dominio (aunque recomendaría confiar sólo en las IP’s). Esto se puede conseguir mediante reglas del cortafuegos, pero eso acaba ralentizando la máquina (especialmente si se añaden multitud de reglas, como tiende a ocurrir). Se puede utilizar TCP_WRAPPERS , pero no sería posible limitar selectivamente el acceso a sitios virtuales, sitios anónimos, sólo al servidor en sí mismo. O se puede hacer en el fichero proftpd.conf utilizando la directiva "
El siguiente ejemplo limitará el acceso a 10.1.*.* y 1.2.3.4, a cualquier otra máquina se le denegará el acceso.
Order Allow, Deny
Allow from 10.1., 1.2.3.4
Deny from all
Si se coloca esto dentro de las directivas "
Si se quiere añadir más accesos anónimos, tan sólo añadir:
User ftp
Group ftp
RequireValidShell off
UserAlias anonymous ftp
MaxClients 10
DisplayLogin bienvenido.msg
DisplayFirstChdir .message
DenyAll
Esto asignaría el directorio personal de los usuarios "ftp" (suponiendo que la configuración normal de "~ftp" probablemente fuese /home/ftp) como el directorio raíz anónimo, cuando la gente hiciese login anónimo, el ProFTPD se ejecutaría como el usuario "ftp" y el grupo "ftp" (al contrario que si se hiciera login como un usuario normal), y los logins anónimos se limitarían a 10. De igual forma, el fichero /home/ftp/bienvenido.msg se mostraría cuando hiciesen ftp los usuarios anónimos, y cualquier directorio con un fichero .message que contuviera texto, el cual se mostraría al cambiar a tal directorio. El "
AllowAll
DenyAll
Lo cual le permitiría a la gente escribir ficheros en /home/ftp/incoming, pero no leerlos (es decir, descargarlos). Como se puede ver, ProFTPD es muy flexible, lo cual da como resultado mayores requerimientos de potencia que el WU-FTPD, pero definitivamente merece la pena por el control añadido. ProFTPD y su documentación se pueden conseguir en: http://www.protftpd.org/∞
proftpd-ldap
El proftpd-ldap te permite hacer consultas por contraseñas utilizando un directorio LDAP, se puede descargar de: http://horde.net/~jwm/software/proftpd-ldap/∞
NcFTPD
El NcFTPD es un servidor ftp de gran volumen, sin embargo sólo se encuentra disponible para uso personal o educativo. Se puede conseguir en: http://www.ncftpd.com/ncftpd∞.
BSD ftpd
El servidor ftp de BSD (ftpd) también se ha transportado a Linux, de modo que si necesitas ejecutarlo, se puede descargar de: ftp://quatramaran.ens.fr/pub/madore/ftpd-BSD/∞
Muddleftpd
El Muddleftpd is un pequeño servidor de ftp. Se puede conseguir en: http://www.computing.edu.au/~kuiperba/muddleftpd/∞.
Troll ftpd
El Troll ftpd es un servidor ftp extremadamente pequeño y relativamente seguro. No puede ejecutar programas externos, y es bastante fácil de configurar. Se puede conseguir en: http://www.troll.no/freebies/ftpd.html∞.
BetaFTPD
El BetaFTPD es un pequeño servidor ftp de un solo hilo. Se puede conseguir en: http://members.xoom.com/_XOOM/sneeze/betaftpd.html∞.
FTP - SSL
Otro reemplazo de tu ftpd favorito (probablemente WU-FTPD), también disponible como un conjunto de parches para el WU-FTPD. Es altamente apropiado, puesto que la mayoría de los servidores tienen muchos usuarios que necesitan acceso ftp. El tarball está disponible en: ftp://ftp.uni-mainz.de/pub/internet/security/ssl/∞, y como paquetes RPM en ftp://ftp.replay.com/pub/replay/linux/redhat/∞
FTP - SRP
El SRP también se puede utilizar para cifrar la porción nombre de usuario / contraseña de tu sesión ftp, o de la sesión completa. Se puede conseguir en: http://srp.arcot.com/srp/∞
SSH
SSH es un protocolo seguro y un conjunto de herramientas para reemplazar otras más comunes (inseguras). Fue diseñado desde el principio para ofrecer un máximo de seguridad y permitir el acceso remoto a servidores de forma segura. SSH se puede utilizar para asegurar cualquier tráfico basado en red, configurándolo como un pipe (p. ej., vinculándolo a cierto puerto en ambos extremos). Es bastante cutre, pero está bien para utilizar X a través de Internet. Además de esto, los componentes del servidor se ejecutan en la mayoría de sistemas UNIX, y NT, y los componentes del cliente se ejecutan en casi cualquier cosa. Por desgracia SSH ya no es gratis; sin embargo hay un proyecto para crear una implementación gratis del protocolo SSH.
No existen tantos problemas con el SSH per se como existen con telnet, todo el tráfico de la sesión va cifrado y el intercambio de llaves se hace de forma relativamente segura (opcionalmente se pueden precargar las llaves al final, para evitar que sean transmitidas y ser vulnerables a ataques tipo ‘man in the middle’, hombre de por medio. SSH se suele ejecutar como un demonio, y se puede cerrar utilizando el fichero sshd_config. También se puede ejecutar sshd desde inetd, y de tal forma utilizar TCP_WRAPPERS, y por defecto los rpm’s de ftp://ftp.replay.com/∞ tienen la opción de TCP_WRAPPERS compilada. De modo que utilizar "sshd: blahblah" en hosts.allow y hosts.deny te permite restringir con facilidad el acceso a ssh. Por favor, ten en cuenta que las primeras versiones de ssh contienen bugs, y se han hackeado sitios (generalmente con ataques tipo ‘man in the middle’ o problemas de desbordamientos de pila en el código ssh), pero la última versión de ssh tiene en cuenta estos problemas. El principal asunto con ssh es su licencia, sólo es gratis para usos no comerciales, sin embargo se puede descargar el código fuente de una gran variedad de sitios. Si se quiere instalar ssh con facilidad, hay un script llamado "install-ssh" que descargará, compilará e instalará el ssh sin dolor, está disponible en:
ftp://ftp.yellowdoglinux.com/pub/yellowdog/install-ssh/∞
Las reglas del cortafuegos para ssh son bastante parecidas a telnet. Por supuesto que está TCP_WRAPPERS, el problema con TCP_WRAPPERS es que un atacante se conecta al puerto, pero no consigue un demonio, SIN EMBARGO sabe que hay algo en ese puerto, mientras que mediante el cortafuegos, ni siquiera se consigue conexión con el puerto. Lo siguiente es un ejemplo de cómo permitir a la gente ejecutar ssh desde máquinas internas, y ciertas clases C en Internet (por ejemplo la clase C que utiliza tu PSI para su batería de módems de acceso).
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 22
ipfwadm –I –a accept –P tcp –S bateria.módems.psi/24 –D 0.0.0.0/0 22
ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 22
o
ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 22
ipchains –A input –p tcp –j ACCEPT –s bateria.módems.psi/24 –d 0.0.0.0/0 22
ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 22
O vía TCP_WRAPPERS
hosts.allow:
sshd: 10.0.0.0/255.0.0.0, bateria.módems.psi/255.255.255.0
hosts.deny:
sshd: 0.0.0.0/0.0.0.0
Además de esto, por defecto el ssh trae un fenomenal fichero de configuración, /etc/sshd/sshd_config en la mayoría de las instalaciones. Se puede restringir con facilidad a quién se le permite hacer login, qué hosts, y qué tipo de autentificación les está permitido utilizar. El fichero de configuración por defecto es relativamente seguro, pero lo que sigue es uno más seguro con explicaciones. Ten en cuenta que toda esta información se puede obtener con un "man sshd", la cual es una de las pocas páginas que están bien escritas. Lo que sigue es un fichero sshd-config típico:
Port 22
# se ejecuta en el puerto 22, el standard
ListenAddress 0.0.0.0
# escucha en todos los interfaces, quizás sería prefirible vincularlo
# sólo a un cortafuegos interno, etc.
HostKey /etc/ssh/ssh_host_key
# dónde se encuentra la llave del host
RandomSeed /etc/ssh/ssh_random_seed
# dónde se encuentra la simiente aleatoria
ServerKeyBits 768
# durante cuanto tiempo dura la llave del servidor
LoginGraceTime 300
# cuánto tiempo se tiene para introducir las credenciales
KeyRegenerationInterval 3600
# cada cuánto tiempo se regeneran las llaves del servidor
PermitRootLogin no
# permitir hacer login al root? ni hablar
IgnoreRhosts yes
# ignorar los ficheros .rhosts de los usuarios? Pues claro
StrictModes yes
# para asegurarse de que los usuarios no hacen tonterías
QuietMode no
# Si es sí no hace log de nada. Queremos hacer log de logins/etc.
X11Forwarding no
# ¿reenviar X11? no habría por qué en un servidor
FascistLogging no
# quizás no querramos hacer demasiado log
PrintMotd yes
# mostrar el mensaje del día? Siempre está bien
KeepAlive yes
# se asegura de que las sesiones se desconectan correctamente
SyslogFacility DAEMON
# ¿quién está haciendo el logging?
RhostsAuthentication no
# la autentificación está usando rhosts o /etc/hosts.equiv No está
# en mi mente. Por defecto es sí, de modo que se desactiva.
RSAAuthentication yes
# permitir autentificación RSA pura? Es bastante segura
PasswordAuthentication yes
# permitir a los usuarios que utilicen su login/contraseña habitual?
# Por qué no.
PermitEmptyPasswords no
# permitir cuentas con contraseñas vacias? no
Otras directivas sshd_conf útiles incluyen:
AllowGroups – permitir a grupos explícitamente (/etc/group) hacer login utilizando ssh
DenyGroups – deshabilitar explícitamente hacer login a grupos (/etc/groups)
DenyUsers – bloquear explícitamente a los usuarios el hacer login
AllowHosts – permitir ciertos hosts, al resto se les denegará
DenyHosts – bloquea ciertos hosts, al resto se les permitirá
IdleTimeout time – tiempo en minutos/horas/días/etc, que fuerza un logout haciendo un SIGHUP del proceso.
Software SSH
Fresh Free FiSSH
La mayoría de nosotros todavía nos tenemos que sentar frente a estaciones windows, y los clientes ssh para windows son bastante difíciles de encontrar. Fresh Free FiSSH es un cliente ssh gratuito para Windows 95/NT 4.0. Aunque todavía no está completado, recomendaría echarle un vistazo si eres como yo y tienes muchas estaciones Windows. La URL es: http://www.massconfusion.com/ssh/∞
Tera Term
Tera Term es un cliente gratuito para Windows y tiene una DLL añadida para soportar ssh. Tera Term está disponible en: http://hp.vector.co.jp/authors/VA002416/teraterm.html∞. La DLL añadida para soporte SSH se encuentra disponible en: http://www.zip.com.au/~roca/ttssh.html∞
putty
putty es un cliente SSH para Windows, bastante bueno, y completamente gratis, además de pequeño (184k en la actualidad). Se puede descargar de: ftp://rak.isternet.sk/mnt/rhcd/misc/putty/∞
mindterm
mindterm es un cliente gratuito de ssh en java, se puede conseguir en: http://www.mindbright.se/mindterm/∞
LSH
LSH es una implementación gratuita del protocolo SSH (ambos cliente y servidor), LSH trae licencia GNU y se está empezando a parecer a la alternativa (comercialmente hablando) a SSH (que ya no es gratis). Se puede descargar de: http://www.net.lut.ac.uk/psst/∞, ten en cuenta que está bajo desarrollo.
Secure CRT
Un Telnet/Cliente SSH comercial de software Vandyke. Se puede descargar / comprar en: http://www.vandyke.com/∞
Fsh
Fsh significa "Fast remote command execution", "Ejecución remota rápida de comandos", y en concepto es similar al rsh/rcp. Evita el gasto de tener que estar constantemente creando sesiones cifradas, mediante el uso de un túnel cifrado utilizando SSH o LSH, y ejecutando todos los comandos sobre él. Se puede conseguir en: http://www.lysator.liu.se/fsh/∞
SSH Win32 ports
Existen ports del SSH a Win32 disponibles en: http://guardian.htu.tuwien.ac.at/therapy/ssh/--∞-
No existen tantos problemas con el SSH per se como existen con telnet, todo el tráfico de la sesión va cifrado y el intercambio de llaves se hace de forma relativamente segura (opcionalmente se pueden precargar las llaves al final, para evitar que sean transmitidas y ser vulnerables a ataques tipo ‘man in the middle’, hombre de por medio. SSH se suele ejecutar como un demonio, y se puede cerrar utilizando el fichero sshd_config. También se puede ejecutar sshd desde inetd, y de tal forma utilizar TCP_WRAPPERS, y por defecto los rpm’s de ftp://ftp.replay.com/∞ tienen la opción de TCP_WRAPPERS compilada. De modo que utilizar "sshd: blahblah" en hosts.allow y hosts.deny te permite restringir con facilidad el acceso a ssh. Por favor, ten en cuenta que las primeras versiones de ssh contienen bugs, y se han hackeado sitios (generalmente con ataques tipo ‘man in the middle’ o problemas de desbordamientos de pila en el código ssh), pero la última versión de ssh tiene en cuenta estos problemas. El principal asunto con ssh es su licencia, sólo es gratis para usos no comerciales, sin embargo se puede descargar el código fuente de una gran variedad de sitios. Si se quiere instalar ssh con facilidad, hay un script llamado "install-ssh" que descargará, compilará e instalará el ssh sin dolor, está disponible en:
ftp://ftp.yellowdoglinux.com/pub/yellowdog/install-ssh/∞
Las reglas del cortafuegos para ssh son bastante parecidas a telnet. Por supuesto que está TCP_WRAPPERS, el problema con TCP_WRAPPERS es que un atacante se conecta al puerto, pero no consigue un demonio, SIN EMBARGO sabe que hay algo en ese puerto, mientras que mediante el cortafuegos, ni siquiera se consigue conexión con el puerto. Lo siguiente es un ejemplo de cómo permitir a la gente ejecutar ssh desde máquinas internas, y ciertas clases C en Internet (por ejemplo la clase C que utiliza tu PSI para su batería de módems de acceso).
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 22
ipfwadm –I –a accept –P tcp –S bateria.módems.psi/24 –D 0.0.0.0/0 22
ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 22
o
ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 22
ipchains –A input –p tcp –j ACCEPT –s bateria.módems.psi/24 –d 0.0.0.0/0 22
ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 22
O vía TCP_WRAPPERS
hosts.allow:
sshd: 10.0.0.0/255.0.0.0, bateria.módems.psi/255.255.255.0
hosts.deny:
sshd: 0.0.0.0/0.0.0.0
Además de esto, por defecto el ssh trae un fenomenal fichero de configuración, /etc/sshd/sshd_config en la mayoría de las instalaciones. Se puede restringir con facilidad a quién se le permite hacer login, qué hosts, y qué tipo de autentificación les está permitido utilizar. El fichero de configuración por defecto es relativamente seguro, pero lo que sigue es uno más seguro con explicaciones. Ten en cuenta que toda esta información se puede obtener con un "man sshd", la cual es una de las pocas páginas que están bien escritas. Lo que sigue es un fichero sshd-config típico:
Port 22
# se ejecuta en el puerto 22, el standard
ListenAddress 0.0.0.0
# escucha en todos los interfaces, quizás sería prefirible vincularlo
# sólo a un cortafuegos interno, etc.
HostKey /etc/ssh/ssh_host_key
# dónde se encuentra la llave del host
RandomSeed /etc/ssh/ssh_random_seed
# dónde se encuentra la simiente aleatoria
ServerKeyBits 768
# durante cuanto tiempo dura la llave del servidor
LoginGraceTime 300
# cuánto tiempo se tiene para introducir las credenciales
KeyRegenerationInterval 3600
# cada cuánto tiempo se regeneran las llaves del servidor
PermitRootLogin no
# permitir hacer login al root? ni hablar
IgnoreRhosts yes
# ignorar los ficheros .rhosts de los usuarios? Pues claro
StrictModes yes
# para asegurarse de que los usuarios no hacen tonterías
QuietMode no
# Si es sí no hace log de nada. Queremos hacer log de logins/etc.
X11Forwarding no
# ¿reenviar X11? no habría por qué en un servidor
FascistLogging no
# quizás no querramos hacer demasiado log
PrintMotd yes
# mostrar el mensaje del día? Siempre está bien
KeepAlive yes
# se asegura de que las sesiones se desconectan correctamente
SyslogFacility DAEMON
# ¿quién está haciendo el logging?
RhostsAuthentication no
# la autentificación está usando rhosts o /etc/hosts.equiv No está
# en mi mente. Por defecto es sí, de modo que se desactiva.
RSAAuthentication yes
# permitir autentificación RSA pura? Es bastante segura
PasswordAuthentication yes
# permitir a los usuarios que utilicen su login/contraseña habitual?
# Por qué no.
PermitEmptyPasswords no
# permitir cuentas con contraseñas vacias? no
Otras directivas sshd_conf útiles incluyen:
AllowGroups – permitir a grupos explícitamente (/etc/group) hacer login utilizando ssh
DenyGroups – deshabilitar explícitamente hacer login a grupos (/etc/groups)
DenyUsers – bloquear explícitamente a los usuarios el hacer login
AllowHosts – permitir ciertos hosts, al resto se les denegará
DenyHosts – bloquea ciertos hosts, al resto se les permitirá
IdleTimeout time – tiempo en minutos/horas/días/etc, que fuerza un logout haciendo un SIGHUP del proceso.
Software SSH
Fresh Free FiSSH
La mayoría de nosotros todavía nos tenemos que sentar frente a estaciones windows, y los clientes ssh para windows son bastante difíciles de encontrar. Fresh Free FiSSH es un cliente ssh gratuito para Windows 95/NT 4.0. Aunque todavía no está completado, recomendaría echarle un vistazo si eres como yo y tienes muchas estaciones Windows. La URL es: http://www.massconfusion.com/ssh/∞
Tera Term
Tera Term es un cliente gratuito para Windows y tiene una DLL añadida para soportar ssh. Tera Term está disponible en: http://hp.vector.co.jp/authors/VA002416/teraterm.html∞. La DLL añadida para soporte SSH se encuentra disponible en: http://www.zip.com.au/~roca/ttssh.html∞
putty
putty es un cliente SSH para Windows, bastante bueno, y completamente gratis, además de pequeño (184k en la actualidad). Se puede descargar de: ftp://rak.isternet.sk/mnt/rhcd/misc/putty/∞
mindterm
mindterm es un cliente gratuito de ssh en java, se puede conseguir en: http://www.mindbright.se/mindterm/∞
LSH
LSH es una implementación gratuita del protocolo SSH (ambos cliente y servidor), LSH trae licencia GNU y se está empezando a parecer a la alternativa (comercialmente hablando) a SSH (que ya no es gratis). Se puede descargar de: http://www.net.lut.ac.uk/psst/∞, ten en cuenta que está bajo desarrollo.
Secure CRT
Un Telnet/Cliente SSH comercial de software Vandyke. Se puede descargar / comprar en: http://www.vandyke.com/∞
Fsh
Fsh significa "Fast remote command execution", "Ejecución remota rápida de comandos", y en concepto es similar al rsh/rcp. Evita el gasto de tener que estar constantemente creando sesiones cifradas, mediante el uso de un túnel cifrado utilizando SSH o LSH, y ejecutando todos los comandos sobre él. Se puede conseguir en: http://www.lysator.liu.se/fsh/∞
SSH Win32 ports
Existen ports del SSH a Win32 disponibles en: http://guardian.htu.tuwien.ac.at/therapy/ssh/--∞-
Suscribirse a:
Entradas (Atom)
