Básicamente, la idea es utilizarlo como herramienta durante la securización de nuestro sistema cuando no tenemos la posibilidad de utilizar una máquina remota para lanzar pruebas de seguridad de red y escaneos de puertos, algo necesario cuando estamos realizando configuraciones en nuestro firewall. No voy a entrar en posibles usos maliciosos que se le puedan dar a la herramienta. Es recomendable leer los TOS para tener claro que y que no se puede hacer, lo que se guardan en los registros de ese servidor, el tiempo que permanecen ahí esos datos, si son públicos, etc.

Como veis en la imagen, podemos realizar un escaneo rápido, completo o personalizado, especificando los parámetros de Nmap igual que lo haríamos en la línea de comandos.

También te puede interesar:

• Hacer persistentes los cambios en ulimit (limits.conf)
• Encriptar un filesystem con LUKS y cryptsetup
• 10 trucos para securizar PHP
• Comando chage: tiempo de vida de claves y usuarios en GNU/Linux

Como ya sabéis la mayoría, el comando ulimit -a nos dice los valores y límites establecidos para nuestro usuario:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Los que más se suelen cambiar son el número de ficheros abiertos de forma simultanea por el usuario, el número de procesos por usuario, ciclos de cpu, etc. Para nuestra sesión, lo solemos hacer directamente en la línea de comandos:

# ulimit -n
1024
# ulimit -n 2048
# ulimit -n
2048

Si salimos de la sesión y entramos de nuevo, el valor volverá a ser 1024. En el caso de Red Hat y derivados, así como Debian debemos especificar estos valores en el fichero /etc/security/limits.conf, así los haremos persistentes.

El propio fichero está perfectamente documentado con comentarios, sino, también tenemos la página man de limits.conf para más información:

$ man limits.conf

# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#            
#
#Where:
# can be:
#        - an user name
#        - a group name, with @group syntax
#        - the wildcard *, for default entry
#        - the wildcard %, can be also used with %group syntax,
#                 for maxlogin limit
#        - NOTE: group and wildcard limits are not applied to root.
#          To apply a limit to the root user,  must be
#          the literal username root.
#
# can have the two values:
#        - "soft" for enforcing the soft limits
#        - "hard" for enforcing hard limits
#
# can be one of the following:
#        - core - limits the core file size (KB)
#        - data - max data size (KB)
#        - fsize - maximum filesize (KB)
#        - memlock - max locked-in-memory address space (KB)
#        - nofile - max number of open files
#        - rss - max resident set size (KB)
#        - stack - max stack size (KB)
#        - cpu - max CPU time (MIN)
#        - nproc - max number of processes
#        - as - address space limit (KB)
#        - maxlogins - max number of logins for this user
#        - maxsyslogins - max number of logins on the system
#        - priority - the priority to run user process with
#        - locks - max number of file locks the user can hold
#        - sigpending - max number of pending signals
#        - msgqueue - max memory used by POSIX message queues (bytes)
#        - nice - max nice priority allowed to raise to values: [-20, 19]
#        - rtprio - max realtime priority
#        - chroot - change root to directory (Debian-specific)
#
#                 
#

#*               soft    core            0
#root            hard    core            100000
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#ftp             -       chroot          /ftp
#@student        -       maxlogins       4

También te puede interesar:

• The Debian Administrator’s Handbook
• Nmap Online para tu IP o Clase C
• FAQ de RHCS (Red Hat Cluster Suite)
• Red Hat Cluster: “generic error” al crear un IP Resource

Vamos a encriptar un sistema de ficheros de un disco secundario sobre un sistema RHEL 6 (CentOS). Para encriptar particiones de sistema (filesystem / o /home por ejemplo) es preferible hacerlo en el momento de la instalación, ya que resulta más sencillo y evitamos la pérdida de datos posterior.

Preparación del sistema

Para la encriptación con LUKS necesitamos tener cargado el módulo de kernel dm_crypt así como el paquete cryptsetup-luks:

# lsmod | grep dm_cry
dm_crypt               10848  0
dm_mod                 63859  5 dm_crypt,dm_mirror,dm_log

Si no está cargado en vuestro sistema hacedlo con modprobe:

# modprobe dm_crypt

Acordaos de configurarlo (por defecto es probable que con modprobe sea suficiente) para que sea persistente a reinicios.

Instalamos cryptsetup-luks en caso de que no esté instalado:

# yum install cryptsetup-luks

# rpm -qa | grep cryptse
cryptsetup-luks-libs-1.1.2-2.el6.i686
cryptsetup-luks-1.1.2-2.el6.i686

Preparación del sistema de ficheros/partición

Vamos a asumir que tenemos ya el sistema de ficheros creado. Podéis revisar los siguientes artículos si tenéis dudas, tanto de crear una partición estándar como un LVM:

• Gestión de LVM en Linux (Logical Volume Manager)
• Crear y eliminar particiones con fdisk en Linux

Algo recomendable pero que suele llevar bastante tiempo es, lo primero de todo, llenar de datos aleatorios la partición a encriptar. Repito que puede llevar bastante tiempo dependiendo del tamaño de la partición. Si sólo estáis haciendo pruebas no es necesario que lo hagáis (sustituid /dev/volgroup1/logvol1 por vuestra partición o volumen):

# dd if=/dev/urandom of=/dev/volgroup1/logvol1

Encriptación del filesystem

Llegados a este punto ya tenemos el sistema de ficheros preparado para su encriptación. Haremos uso del comando cryptsetup. Lo primero que haremos es asignar la passphrase. Cuanto más compleja sea mejor, igual que cualquier password:

Nota: se eliminará cualquier dato del filesystem

# cryptsetup luksFormat /dev/volgroup1/logvol1

WARNING!
========
This will overwrite data on /dev/volgroup1/logvol1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: *********
Verify passphrase: *********

Al tratarse de un filesystem encriptado debemos mapearlo ya que no se puede leer directamente. Esa unidad mapeada será la que montaremos y utilicemos como un filesystem estándar. Vamos a sacar el UUID del sistema de ficheros encriptado para utilizarlo si queremos en lugar de la etiqueta (LABEL):

# cryptsetup luksUUID /dev/volgroup1/logvol1
79da86ea-70f2-4a80-82cb-6c614a885a37

Mapeamos el sistema de ficheros contra encrypted-fs:

# cryptsetup luksOpen /dev/volgroup1/logvol1 encrypted-fs
Enter passphrase for /dev/volgroup1/logvol1:

Y ya tenemos el volumen listo para particionar en /dev/mapper/encrypted-fs. Le damos formato y lo montamos:

# mkfs.ext4 /dev/mapper/encrypted-fs

Finalmente, lo añadimos a fstab para el arranque al inicio del sistema. Podemos hacerlo con el UUID o con la etiqueta (LABEL) del fs:

# tune2fs -l /dev/mapper/encrypted-fs | grep UUID
Filesystem UUID:          9578a03e-949b-4fe8-a16c-57024b01fe89

Lo añadimos a /etc/fstab:

UUID=9578a03e-949b-4fe8-a16c-57024b01fe89 /encrypted-fs ext4    defaults 0 0

Y añadimos también la siguiente entrada a /etc/crypttab para que solicite la passphrase en el arranque del sistema:

encrypted-fs /dev/volgroup1/logvol1 none

Si reiniciáis, durante el arranque se os solicitará la passphrase del volumen:

logvol1 is password protected: *************

También te puede interesar:

• Encriptación y desencriptación con GnuPG
• Encriptar mensajes de Gmail con FireGPG
• Nmap Online para tu IP o Clase C
• Hacer persistentes los cambios en ulimit (limits.conf)

En esta entrada vamos a ver unos cuantos puntos que nos servirán para securizar PHP en nuestro servidor web. Nos centramos en la configuración propia de PHP, hay que tener en cuenta que la securización de la capa aplicación es tanto o más importante que la de la configuración del servidor. Hay que tener siempre actualizados a la última versión estable y con los parches de seguridad correctamente aplicados cualquier cms o script de terceros tipo WordPress, Joomla, Oscommerce, etc.

Ocultar la versión de PHP

En su día hice un artículo completo sobre esto, podéis verlo aquí (ocultar la versión de PHP). Básicamente evitamos que con un simple telnet puedan averiguar la versión de PHP que hay corriendo en el servidor:

# telnet servidor 80

Connected to xxx.com (xx.xx.xx.xx).
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 13 Aug 2010 14:18:09 GMT
Server: Apache/1.3.26 (Unix) mod_gzip/1.3.26.1a PHP/5.3.3
Last-Modified: Fri, 12 Feb 2010 12:22:56 GMT
ETag: "44967c-6f-53ca4800"
Accept-Ranges: bytes
Content-Length: 111
Connection: close
Content-Type: text/html

Connection closed by foreign host.

Para evitar esto cambiamos a off la siguiente variable en el fichero de configuración general php.ini:

expose_php Off

Deshabilitar funciones peligrosas

También hice un artículo hace un tiempo: PHP: Deshabilitar funciones peligrosas. Existen funciones que en servidores con aplicaciones estándar rara vez se usan, pero que por contra pueden generar graves problemas de seguridad si el atacante consigue utilizarlas. Es preferible desactivar el mayor número posible y en caso de que una de ellas sea necesario valorar su activación o proponer alternativas.

Las funciones a deshabilitar se añaden en la directiva “disable_functions” en el fichero php.ini. Aquí tenéis un ejemplo con funciones peligrosas que conviene desactivar:

disable_functions = “apache_child_terminate, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, xmlrpc_entity_decode”

O un ejemplo más conservador:

disable_functions ="system,passthru,escapeshellarg,escapeshellcmd,proc_close,proc_open,ini_alter,popen,show_source,pcntl_exec"

deshabilitar session ID en URL

Si queremos que las URL’s de nuestros sitios PHP no muestren los ID de sesiones:

http://ejemplo.com/?PHPSESSID=4kgj577sgabvnmhjgkdiuy1956if6ska

Modificamos la directiva siguiente en el fichero php.ini:

session.use_trans_sid = off

Deshabilitar register_globals

Pese a ser una directiva antigua y que se encuentra en periodo de extinción todavía quedan desarrolladores/programadores que la utilizan. Esta función permite al atacante manipular cualquier variable global definida en la programación. Por defecto está deshabilitada en las versiones actuales de PHP, pero conviene revisarlo por si en algún momento se ha activado:

register_globals = Off

Desactivar acceso a URL remotas en funciones de manejo de ficheros

Funciones como include, fopen o file_get_contents permiten, además de hacer llamadas a ficheros locales, llamar a ficheros vía URL, esto puede provocar graves errores de seguridad invocando a scripts maliciosos que se encuentran fuera de nuestro servidor y su ejecución remota.

Para deshabilitarlo modificamos la directiva allow_url_fopen a Off en el php.ini:

allow_url_fopen = Off

Evitar el acceso a la información de PHP

Como ya sabéis con un simple script como el siguiente podemos ver vía URL toda la información de PHP, su compilación, sus módulos activados, versión, directivas de configuración, etc.

<? phpinfo() ?>

Si queremos desactivarlo, únicamente hay que modificar a Off la siguiente directiva en el fichero php.ini:

expose_php = Off

Si en algún momento necesitáis conocer alguna información, siempre podéis averiguarla desde línea de comandos: información sobre PHP desde línea de comandos

Safe Mode

safe_mode = On

Si bien por defecto safe_mode On puede significar una restricción demasiado fuerte en determinados entornos, puede ayudar mucho a incrementar la seguridad de nuestro servidor. Activar safe_mode implica que los scripts PHP únicamente pueden acceder a los ficheros que tienen como propietario el mismo que ellos. De este modo evitamos por ejemplo que tengan acceso de lectura a ficheros de sistema como /etc/passwd entre otros.

Efectivamente, esto puede ser un problema en el momento que necesitamos acceder a información generada por otros usuarios en el sistema (ficheros de otras aplicaciones. La solución es la siguiente:

safe_mode = Off
safe_mode_gid = On

Activamos safe_mode_gid en lugar de safe_mode, de modo que en lugar de revisar el usuario se revisa el grupo. Independientemente del UID del fichero, necesitaremos que estar dentro del grupo para poder acceder al ficheros. El grupo del script PHP deberá ser el mismo que el del fichero a acceder.

Otro punto a tener en cuenta con safe_mode es que no podremos ejecutar binarios. Únicamente aquellos que ubiquemos en el directorio especificado en la configuración:

safe_mode_exec_dir = /directorio

Esto se solaparía con las funciones deshabilitadas anteriormente, como por ejemplo system() o exec().

open_basedir

open_basedir = /directorio

La directiva open_basedir permite configurar que PHP pueda acceder únicamente a los ficheros de un único directorio (y sus subdirectorios). Es una buena forma de enjaular PHP si realmente sólo necesitamos que acceda a un determinado directorio.

Visualización y registro de errores

display_errors = Off
log_errors = On
error_log = /ruta/fichero/log

Con estas tres directivas, evitamos que cualquier error o warning se muestre por pantalla y hacemos que se registren directamente en un log especificado. De este modo podemos evitar que se muestre información sensible por pantalla. También podéis hacer uso de la directiva error_reporting si queréis mostrar por pantalla los errores. Con ella podéis especificar que se muestren únicamente los warning, los notice o lo que queráis.

SQL Injection

En su día se utilizaba magic_quotes para limpiar los datos de entrada de un script PHP, pero es una directiva obsoleta a partir de PHP 5.3 así que no merece la pena hablar de ella. En su defecto, si usáis servidor web Apache, os recomiendo encarecidamente configurar mod_security y habilitar sus reglas que permiten detectar y parar una gran cantidad de ataques de este tipo, y sino, puedes crear tus propias reglas.

Como último apunte, conviene siempre si es posible mantener una versión estable de PHP, libre de bugs y fallos de seguridad. Seguro además que una vez aplicados estos trucos os toca lidiar con los programadores. Se quejarán de algo seguro ;)

También te puede interesar:

• Ocultar la versión de PHP
• Nmap Online para tu IP o Clase C
• Vulnerabilidad crítica en instalaciones de PHP basadas en CGI
• Hacer persistentes los cambios en ulimit (limits.conf)

Echando un vistazo a la ayuda del comando vemos claramente la función de cada uno de los parámetros:

$ chage --help
Modo de uso: chage [opciones] [USUARIO]

Opciones:
  -d, --lastday ULTIMO_DÍA      establece el último cambio de clave a
                                ULTIMO_DÍA
  -E, --expiredate FECHA_EXP    establece la fecha de caducidad de la
                                cuenta a FECHA_EXP
  -h, --help                    muestra este mensaje de ayuda y termina
  -I, --inactive INACTIV        desactiva la cuenta después de INACTIV
                                días desde la fecha de expiración
  -l, --list                    muestra la información de envejecimiento
                                de la cuenta
  -m, --mindays DÍAS_MIN        establece el número mínimo de días antes
                                de cambiar la clave a DÍAS_MIN
  -M, --maxdays DÍAS_MAX        establece el número máximo de días antes
                                de cambiar la clave a DÍAS_MAX
  -W, --warndays DÍAS_AVISO     establece el número de días de aviso
                                a DÍAS_AVISO

Como podéis ver, se puede especifica la fecha exacta en la que expirará la clave de acceso, los días permitidos tras la expiración de la cuenta hasta que se desactiva por completo, los días de aviso, etc. Vamos a ver unos ejemplos:

Cambiar la fecha de expiración de la cuenta al día 2011-9-28 al usuario foo

# chage -E 2011-9-28 foo

Listamos los atributos de caducidad especificados para esta cuenta:

# chage -l foo
Último cambio de contraseña					: sep 07, 2011
La contraseña caduca					: nunca
Contraseña inactiva					: nunca
La cuenta caduca						: sep 28, 2011
Mínimo número de días entre cambios de contraseña		: 0
Máximo número de días entre cambios de contraseña		: 99999
Número de días de aviso antes de que caduque la contraseña	: 7

Cambiar número de días entre cambios de clave (15) y la caducidad por inactividad de la clave (150)

# chage -m 15 -M 15 -I 150 foo
# chage -l foo
Último cambio de contraseña					: sep 07, 2011
La contraseña caduca					: sep 22, 2011
Contraseña inactiva					: feb 19, 2012
La cuenta caduca						: sep 28, 2011
Mínimo número de días entre cambios de contraseña		: 15
Máximo número de días entre cambios de contraseña		: 15
Número de días de aviso antes de que caduque la contraseña	: 7

Obligar a cambiar la clave en el próximo intento de acceso

# chage -d 0 foo

También te puede interesar:

• Configurar la caducidad de claves en Linux
• Permisos especiales (setuid, setgid, sticky bit)
• Securizando y optimizando Linux
• Bucle de password expirado en ldap nativo RHEL contra Sun LDAP

TCP Wrapper (“Envoltorio de TCP”) es un sistema de red ACL que trabaja en terminales y que se usa para filtrar el acceso de red a servicios de protocolos de Internet que corren en sistemas operativos (tipo UNIX), como Linux o BSD. Permite que las direcciones IP, los nombres de terminales y/o respuestas de consultas ident de las terminales o subredes sean usadas como tokens sobre los cuales filtrar para propósitos de control de acceso.

Bien, partimos de la base de que tenemos dos ficheros configurables, /etc/hosts.deny y /etc/hosts.allow. En ellos podemos especificar que IPs, hostnames o redes pueden acceder a determinados servicios del sistema. TCP Wrappers suele venir instalado por defecto en la mayoría de sistemas operativos Unix.

La sintaxis básica de estos ficheros es la siguiente:

daemon : dirección : acción
ó
daemon : dirección

Daemon es el demonio/servicio a filtrar, dirección es la dirección, host o subred y acción si denegamos o aceptamos el acceso. Para saber si un servicio puede ser configurado para filtrado vía TCP Wrappers hay que saber si su binario está enlazado con la biblioteca libwrap.a. Para ello:

# ldd /usr/sbin/sshd | grep libwrap.so
	libwrap.so.0 => /lib/libwrap.so.0 (0x001ce000)

Si la salida es NULL el demonio no está compilado con TCP Wrappers y no funcionará. Si devuelve algo como lo anterior sí que lo está. Vamos a ver entonces unos cuantos ejemplos:

Permitir acceso ssh únicamente a unas IPs

/etc/hosts.allow Permitimos acceso a las IPs 192.168.0.111, 192.168.0.112, 192.168.0.113.

sshd: 192.168.0.111 192.168.0.112 192.168.0.113

/etc/hosts.deny Denegamos al resto.

sshd: ALL

Bloquear todo excepto lo declarado en /etc/hosts.allow

/etc/hosts.allow

sshd: 192.168.0.111 192.168.0.112 192.168.0.113

/etc/hosts.deny Denegamos acceso al resto de servicios excepto SSH a las Ips indicadas. La máquina quedará blindada excepto el acceso SSH a las Ips permitidas:

ALL: ALL

Permitir también el uso de sendmail a una subred y unos hosts concretos

/etc/hosts.allow Permitimos acceso a las IPs 192.168.0.111, 192.168.0.112, 192.168.0.113.

sshd: 192.168.0.111 192.168.0.112 192.168.0.113
sendmail: 10.0.0.0/24 test.com prueba.com

/etc/hosts.deny

ALL: ALL

Permitir todo y bloquear el acceso total a una única IP

/etc/hosts.allow

ALL: ALL

/etc/hosts.deny

ALL: 192.168.0.115

Filtrar y ejecutar un comando tras un intento de acceso

/etc/hosts.allow

ALL: ALL

/etc/hosts.deny

ALL: 192,168.0.115 \
   : spawn (/bin/echo %a desde %h intento acceder a %d >> \
    /var/log/connections.log) \
   : deny

Aquí ya depende todo si queremos aplicar una política restrictiva desde el principio, bloquear todo y a partir de ahí comenzar a abrir servicios a determinadas Ips, rangos o hosts o si por el contrario queremos dejar todo abierto y cerrar servicios a determinadas Ips,etc.

Si os resulta interesante, disponéis de más información en el handbook de freebsd o en Linux about.com. Esta ha sido una mera introducción a TCP Wrappers

También te puede interesar:

• Nmap Online para tu IP o Clase C
• Hacer persistentes los cambios en ulimit (limits.conf)
• Configurar el puerto TCP como estático en una instancia SQL Server 2008
• Encriptar un filesystem con LUKS y cryptsetup

setuid

EL bit setuid es asignable a ficheros ejecutables, y permite que cuando un usuario ejecute dicho fichero, el proceso adquiera los permisos del propietario del fichero ejecutado. El ejemplo más claro de fichero ejecutable y con el bit setuid el

.

sirve para ejecutar una shell con identificadores de grupo y de usuario distintos al nuestro, por ello ha de tener este bit y así permitir adquirir al usuario temporalmente permisos administrativos para poder hacer el cambio de usuario.

Podemos ver que el bit está asignado (s) haciendo un ls:

$ ls -l /bin/su
-rwsr-xr-x 1 root root 31012 2009-04-04 07:49 /bin/su

Para asignar este bit a un fichero:

# chmod u+s /bin/su

Y para quitarlo:

# chmod u-s /bin/su

Lógicamente, conviene utilizar este bit con extremo cuidado ya que puede provocar una escalada de privilegios en situaciones inseguras. Para que veáis un ejemplo de lo que se podría hacer.

El usuario “alex” no tiene permisos para ejecutar correctamente un fdisk -l:

alex@linux:~$ fdisk -l

La salida es 0, pero si asignamos el bit setuid al binario de fdisk…

# ls -l /sbin/fdisk
-rwsr-xr-x 1 root root 93048 2009-02-18 20:43 /sbin/fdisk

Probamos de nuevo a ejecutar fdisk con el usuario “alex” y conseguimos privilegios de root:

alex@linux:~$ fdisk -l

Disco /dev/sda: 160.0 GB, 160041885696 bytes
255 cabezas, 63 sectores/pista, 19457 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Identificador de disco: 0x000c3c51

Dispositivo Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sda1   *           1        3232    25959424    7  HPFS/NTFS
/dev/sda2            3233        9683    51817657+  83  Linux
/dev/sda3            9684        9855     1381590   82  Linux swap / Solaris
/dev/sda4            9856       19457    77128065   83  Linux

Luego nos acordamos de volver a quitarlo:

# chmod u-s /sbin/fdisk

setgid

Si el bit setuid permitía que el proceso adquiriera los permisos del propietario del fichero ejecutado, setgid hace lo mismo pero adquiriendo los privilegios del grupo asignado al fichero, también es asignable a directorios. Este bit entonces será muy útil cuando varios usuarios de un mismo grupo necesiten trabajar con recursos dentro de un mismo directorio.

En el siguiente ejemplo asignamos el bit setgid la carpeta /compartido, le asignamos permisos totales para el propietario y el grupo (770) y el bit segid (2):

$ mkdir compartido && chmod 2770 /compartido

Si hacemos un ls veremos el bit asignado:

$ ls -l
drwxrws--- 2 alex alex      4096 2011-04-24 21:27 compartido

Ahora vamos a hacer la prueba de crear un fichero dentro del directorio. Lo vamos a crear estando autenticados como root, pero al tener el bit setgid le asignará el grupo “alex” en lugar de root.

$ su
# touch test
root@sistemas:/home/alex/compartido# ls -l
total 0
-rw-r--r-- 1 root alex 0 2011-04-24 21:28 test
# whoami
root

En lugar de modo octal podéis asignar también los permisos setgid del siguiente modo:

$ chmog g+s /compartido

Y quitarlo:

$ chmog g-s /compartido

sticky

Este bit suele asignarse en directorios a los que todos los usuarios tienen acceso, y permite evitar que un usuario pueda borrar ficheros/directorios de otro usuario dentro de ese directorio, ya que todos tienen permiso de escritura. Seguro que lo estáis pensando, este bit se asigna siempre en /tmp y /var/tmp.

tmp tiene permisos 777, el bit sticky se asignaría del siguiente modo:

# chmod 1777 /tmp

También así:

chmod o+t /tmp

Y para quitarlo:

chmod o-t /tmp

Si hacemos un ls veremos la “t” asignada:

drwxrwxrwt  13 root root  4096 2011-04-24 20:55 tmp

Esta es una visión general de estos tres bits especiales asignables a ficheros ejecutables y directorios en Unix/Linux.

También te puede interesar:

• El comando umask
• Comando chage: tiempo de vida de claves y usuarios en GNU/Linux
• Diferencias entre soft (symbolic) y hard links
• Gestión de trabajos en BASH (jobs, fg, bg, &…)

Una vez dentro ya podemos visualizar configurar el comportamiento por defecto (permitir o denegar acceso a todo el mundo) y las excepciones:

Aquí es donde podemos añadir nombres de dominio, rangos e IPs tanto para denegar acceso como permitir (según la configuración por defecto establecida).

También te puede interesar:

• Nmap Online para tu IP o Clase C
• Hacer persistentes los cambios en ulimit (limits.conf)
• Encriptar un filesystem con LUKS y cryptsetup
• 10 trucos para securizar PHP

Mediante passwd podemos forzar que la clave de un usuario caduque pasados X días., Así mismo, también podemos configurar el número de días que el usuario será avisado antes del cambio obligado de clave y el número de días una vez pasado este límite hasta que la cuenta se desactive.

Estos tres parámetros son los siguientes:

-x, --maxdays DÍAS_MÁX        establece a DÍAS_MÁX el número máximo de días antes del cambio de la contraseña
-w, --warndays DÍAS_AVISO     establece los días de aviso de expiración a DÍAS_AVISO
-i, --inactive INACTIVO       establece la inactividad de la contraseña tras su expiración a INACTIVO

Vamos a poner un ejemplo, si quisieramos que la clave del usuario “pruebas” caducara pasados 180 días, que le avisara durante los cinco últimos días de validez de la clave, y que si tras pasados 15 días sin modificar la clave se bloqueara, utilizaríamos la siguiente línea de comandos:

# passwd pruebas -x 180 -w 5 -i 15

También te puede interesar:

• Comando chage: tiempo de vida de claves y usuarios en GNU/Linux
• Permisos especiales (setuid, setgid, sticky bit)
• Securizando y optimizando Linux
• Bucle de password expirado en ldap nativo RHEL contra Sun LDAP

En este caso vamos a ocultar la versión de PHP, es extremadamente sencillo. Únicamente hay que editar el fichero de configuración general php.ini y modificar el siguiente parámetro a Off:

expose_php Off

Ya podemos verificar que al hacer la petición contra el sitio web la información PHP ya no se muestra:

# telnet servidor 80

Connected to xxx.com (xx.xx.xx.xx).
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 13 Aug 2010 14:18:09 GMT
Server: Apache
Last-Modified: Fri, 12 Feb 2010 12:22:56 GMT
ETag: "44967c-6f-53ca4800"
Accept-Ranges: bytes
Content-Length: 111
Connection: close
Content-Type: text/html

Connection closed by foreign host.

También te puede interesar:

• 10 trucos para securizar PHP
• Nmap Online para tu IP o Clase C
• Vulnerabilidad crítica en instalaciones de PHP basadas en CGI
• Hacer persistentes los cambios en ulimit (limits.conf)