S2-login: (0.03)
	Prohibir login en las cuentas que no se usan
	(qpopper y apache siguen funcionando)



1) No dar cuenta en la máquina que hace de cortafuegos más que a los usuarios
    indispensables (y si es posible a ninguno).

2) Hacer imposible el login en cuentas que no se usan (solo para qpopper, por
    ejemplo) cambiando el shell en /etc/passwd por /bin/false con:

	usermod -s /bin/false usuario

NOTA: qpopper continua funcionando, aunque el usuario no tenga shell.


3) Si siempre se utiliza "adduser" puede dejarse como shell por defecto
  modificando el archivo /etc/adduser.conf


4) *POR HACER* Revisar los shell en /etc/passwd de las cuentas de sistema,
  muchas pueden no necesitar un shell (por ejemplo www-data)


5) Verificar que las cuentas de sistema no aceptan ningún password
    Como root revisar /etc/shadow y mirar el segundo campo del archivo,
    por ejemplo:
---8<---
www-data:*:11145:0:99999:7:-1:-1:
--->8---

    * = password deshabilitado -> Es lo que trae Potato en cuentas de sistema
    ! = password deshabilitado -> Es lo que pone "adduser --system"
    otra cosa (de 13 a 24 caracteres) = password encriptado
    nada (ni siquiera un espacio) = cuenta sin password (no se pide password)


    NOTA: La función de encriptado NUNCA devuelve un solo carácter, por lo que
    parece que * o ! hacen lo mismo, deshabilitar el passwd...



UN POCO DE TEORÍA:

El shell del archivo /etc/passwd se utiliza para:
    - login	Al entrar en el sistema como ese usuario
    - su	Al hacer "su usuario" para obtener un shell como ese usuario

    ya que ambos leen /etc/passwd para la elección del shell y otras variables

Y no es necesario (puede ser /bin/false) para:
    - cuentas de usuario para que los demonios no corran como root


Un ejemplo apache y cgi-bin:
    En Debian la primera instancia de Apache arranca como root y todas las
    demás lo hacen como usuario "www-data". Por tanto las páginas html son
    leídas y los cgi-bin son ejecutados con los privilegios de www-data

    A primera vista parece que sería preciso un shell en la cuenta www-data
    para que los cgi-bin puedan funcionar... pero no es así (comprobado)

    Seguramente esto funciona así (no he mirado los fuentes):
	- apache utiliza los privilegios de root para abrir el puerto
	 privilegiado 80, por eso arranca como root
	- hace un setuid() o un seteuid() a www-data
	- hace un fork() para cada instancia de apache a servir páginas html
	- los cgi-bin se lanzan con un execve()
	- execve() no mira /etc/passwd, simplemente lanza el proceso con
	 la identidad en curso ya sea un programa ejecutable o un script

¿porque las distribuciones traen shell válidos en las cuentas de sistema?
    Supongo que:
    - Al no admitir password se supone que son razonablemente seguras.
    - Es útil hacer "su cuenta" para "ver en vivo" que puede ver esa cuenta
    - Si un exploit de un cgi-bin da acceso al interprete que ese cgi tiene
     en ese momento (que no depende del shell en /etc/passwd)
     ¿que más da que la cuenta tenga shell?



MOTIVO:
a) Cuantas menos cuentas se puedan utilizar para entrar en el sistema, mas
    seguro es.
b) Las contraseñas de los usuarios (para recoger correo con qpopper) podrían
    ser fáciles de "crackear", mejor si un intruso no puede aprovecharse de
    ello


MAS AYUDA:

man login	(en castellano en potato)
man su		(en castellano en potato)
man shadow
man setuid, man setuid, man execve