Showing posts with label Seguridad en Gnu/Linux. Show all posts
Showing posts with label Seguridad en Gnu/Linux. Show all posts

7/10/2008


Howto de sudo, visudo, sudoers

Copyright 2005-2008 Sergio González Durán
Se concede permiso para copiar, distribuir y/o modificar este documento siempre y cuando se cite al autor y la fuente de linuxtotal.com.mx y según los términos de la GNU Free Documentation License, Versión 1.2 o cualquiera posterior publicada por la Free Software Foundation.

autor: sergio.gonzalez.duran@gmail.com


[ÍNDICE...]

En ambientes donde varios usuarios usan uno o más sistemas GNU/Linux, es necesario otorgar distintos permisos o privilegios para que estos puedan hacer uso de comandos propios del usuario administrador 'root'. Totalmente fuera de lugar e impensable es 'entregar' la contraseña de root para que los usuarios puedan hacer uso de los programas propios de sus funciones pero que son propiedad de 'root'. Por otro lado, hacer uso del comando su tampoco es práctico porque es lo mismo, necesitan la contraseña de root, asi que la mejor alternativa es hacer uso de sudo.

¿Exáctamente que es y que hace sudo?. sudo permite implementar un control de acceso altamente granulado de que usuarios ejecutan que comandos. Si un usuario normal desea ejecutar un comando de root (o de cualquier otro usuario), sudo verifica en su lista de permisos y si está permitido la ejecución de ese comando para ese usuario, entonces sudo se encarga de ejecutarlo. Es decir, sudo es un programa que basado en una lista de control (/etc/sudoers) permite (o no) la ejecución al usuario que lo invocó sobre un determinado programa propiedad de otro usuario, generalmente del administrador del sistema 'root'.

sudo, para fines prácticos se puede dividir en tres partes:

  • sudo, el comando con permisos de SUID, que los usuarios usan para ejecutar otros comandos a los que se les permite usar.
  • visudo, el comando que permite al administrador modificar /etc/sudoers.
  • /etc/sudoers, el archivo de permisos que le indica a sudo que usuarios ejecutan cuáles comandos.

sudo

sudo (SUperuser DO) lo ejecuta un usuario normal, al que se supone tiene permisos para ejecutar cierto comando. Entonces, sudo requiere que los usuarios se autentifiquen a si mismos a través de su contraseña para permitirles la ejecución del comando. Veamos un ejemplo:

$ sudo /sbin/ifconfig
Password:
eth0 Link encap:Ethernet HWaddr 4C:00:10:60:5F:21
inet addr:200.13.110.62 Bcast:200.13.110.255 Mask:255.255.255.0
inet6 addr: fe80::4e00:10ff:fe60:5f21/64 Scope:Link
...

Como se podrá observar se usa el comando sudo seguido del comando (con toda su ruta si es que este no esta en el PATH del usuario) al que se tiene permiso. sudo pregunta por la contraseña del usuario que ejecuta el comando y listo.

Por defecto, después de hacer lo anterior tendrás 5 minutos para volver a usar el mismo comando u otros a los que tuvieras derecho, sin necesidad de ingresar la contraseña de nuevo. Si se quiere extender el tiempo por otros 5 minutos usa la opción sudo -v (validate). Por el contario, si ya terminaste lo que tenías que hacer, puedes usar sudo -k (kill) para terminar con el tiempo de gracia de validación.

Ahora bien, ¿Qué comandos son los que puedo utilizar?, pues la opción -l es la indicada para eso:

$ sudo -l
User sergio may run the following commands on this host:
(root) /sbin/ifconfig
(root) /sbin/lspci

En el caso anterior se ejecutó un comando de root, pero no tiene que ser asi, también es posible ejecutar comandos de otros usuarios del sistema indicando la opción -u:

$ sudo -u ana /comando/de/ana

Una de las opciones más interesantes es la que permite editar archivos de texto de root (claro, con el permiso otorgado en 'sudoers' como se verá más adelante), y esto se logra con la opción -e, esta opción esta ligada a otro comando de sudo llamado sudoedit que invoca al editor por defecto del usuario, que generalmente es 'vi'.

$ sudo -e /etc/inittab
(Permitira modificar el archivo indicado como si se fuera root)

Cuando se configura sudo se tienen múltiples opciones que se pueden establecer, estás se consultan a través de la opción -L

$> sudo -L
Available options in a sudoers ``Defaults'' line:

syslog: Syslog facility if syslog is being used for logging
syslog_goodpri: Syslog priority to use when user authenticates successfully
syslog_badpri: Syslog priority to use when user authenticates unsuccessfully
long_otp_prompt: Put OTP prompt on its own line
ignore_dot: Ignore '.' in $PATH
mail_always: Always send mail when sudo is run
mail_badpass: Send mail if user authentication fails
mail_no_user: Send mail if the user is not in sudoers
mail_no_host: Send mail if the user is not in sudoers for this host
mail_no_perms: Send mail if the user is not allowed to run a command
tty_tickets: Use a separate timestamp for each user/tty combo
lecture: Lecture user the first time they run sudo
lecture_file: File containing the sudo lecture
authenticate: Require users to authenticate by default
root_sudo: Root may run sudo
...
varias opciones más

Bastante útil, ya que nos muestra las opciones y una pequeña descripción, estás opciones se establecen en el archivo de configuración 'sudoers'.

Una de las opciones más importantes de consulta es -V, que permite listar las opciones (defaults) establecidas por defecto para sudo todos los usuarios, comandos, equipos, etc. Más adelante en este tutorial, aprenderemos como establecer opciones específicas para ciertos usuarios, comandos o equipos. NOTA: tienes que ser 'root' para usar esta opción.

# sudo -V
Sudo version 1.6.9p5

Sudoers path: /etc/sudoers
Authentication methods: 'pam'
Syslog facility if syslog is being used for logging: local2
Syslog priority to use when user authenticates successfully: notice
Syslog priority to use when user authenticates unsuccessfully: alert
Send mail if the user is not in sudoers
Lecture user the first time they run sudo
Require users to authenticate by default
Root may run sudo
Log the hostname in the (non-syslog) log file
Allow some information gathering to give useful error messages
Visudo will honor the EDITOR environment variable
Set the LOGNAME and USER environment variables
Reset the environment to a default set of variables
Length at which to wrap log file lines (0 for no wrap): 80
Authentication timestamp timeout: 5 minutes
Password prompt timeout: 5 minutes
Number of tries to enter a password: 3
Umask to use or 0777 to use user's: 022
Path to log file: /var/log/sudo.log
...
varias opciones más listadas

Con intención, trunque el listado anterior en la línea "Path to log file: /var/log/sudo.log", donde se indica cual es el archivo 'log' o de bitacora por defecto de sudo, en este archivo se loguea absolutamente todo lo que se haga con sudo, que usuarios ejecutaron que, intentos de uso, etc.


visudo

Permite la edición del archivo de configuración de sudo sudoers. Invoca al editor que se tenga por defecto que generalemente es 'vi'. visudo cuando es usado, bloquea el archivo /etc/sudoers de tal manera que nadie más lo puede utilizar, esto por razones obvias de seguridad que evitarán que dos o más usuarios administradores modifiquen accidentalmente los cambios que el otro realizó.

Otra característica importande de visudo es que al cerrar el archivo, verifica que el archivo este bien configurado, es decir, detectará si hay errores de sintaxis principalmente en sus múltiples opciones o reglas de acceso que se tengan. Por esta razón no debe editarse /etc/sudoers directamente (perfectamente posible ya que es un archivo de texto como cualquier otro) sino siempre usar visudo.

Si al cerrar visudo detecta un error nos mostrará la línea donde se encuentra, y la pregunta "What now?":

>>> sudoers file: syntax error, line 15 <<<>

Se tienen tres opciones para esta pregunta:

  • e - edita de nuevo el archivo, colocando el cursor en la línea del error (si el editor soporta esta función.)
  • x - salir sin guardar los cambios.
  • Q - salir y guarda los cambios.

Por defecto el archivo de configuración es /etc/sudoers pero se pueden editar otros archivos que no sean ese y que se aplique la sintaxis de sudo, y esto se logra con la opción -f (visudo -f /otro/archivo).

Si tan solo se desea comprobar que /etc/sudoers esta bien configurado se usa la opción -c, toma por el archivo de configuración por defecto o si no se indica algún otro.

#> visudo -c
/etc/sudoers file parsed OK

La opción -s activa el modo 'estricto' del uso de visudo, es decir no solo se comprobará lo sintáctico sino también el orden correcto de las reglas, por ejemplo si se define el alias para un grupo de comandos y este se usa antes de su definición, con esta opción se detectará este tipo de errores.


Sudoers

Archivo de configuración de sudo, generalmente ubicado bajo /etc y se modifica a través del uso de visudo. En este archivo se establece quien (usuarios) puede ejecutar que (comandos) y de que modo (opciones), generando efectivamente una lista de control de acceso que puede ser tan detallada como se desee.

Es más fácil entender sudo si dividimos en tres partes su posible configuración, estás son:

  • Alias
  • Opciones (Defaults)
  • Reglas de acceso

Por extraño que parezca ninguna de las secciones es obligatoria, o tienen que estar en algún orden específico, pero la que al menos debe de existir es la tercera, que es la definción de los controles o reglas de acceso. Se detallará cada uno de estos en un momento. Para los que les gusta saber más la cuestión técnica es interesante saber que la construcción de un archivo sudoers esta basado en la forma BNF (Backus-Naur Form), concretamente en versión extendida (EBNF), si estudiaste algún curso de informática universitario seguramente sabes de lo que hablo. EBNF describe de una forma precisa y exacta la gramática de un lenguaje, esta se va creando a través de reglas de producción que a la vez son la base para ser referenciadas por otras reglas. Afortunadamente no necesitas saber nada de esto, solo entender como se aplican estas reglas.


Alias

Un alias se refiere a un usuario, un comando o a un equipo. El alias engloba bajo un solo nombre (nombre del alias) una serie de elementos que después en la parte de definición de reglas serán refiridos aplicados bajos cierto criterio. Es decir, regresando a EBNF estamos creando las reglas de producción inicial. La forma para crear un alias es la siguiente:


tipo_alias NOMBRE_DEL_ALIAS = elemento1, elemento2, elemento3, ... elementoN

tipo_alias NOMBRE1 = elemento1, elemento2 : NOMBRE2 = elemento1, elemento2

En el segundo caso, separado por ":" es posible indicar más de un alias en una misma definción.


El tipo_alias define los elementos, es decir, dependiendo del tipo de alias serán sus elementos. Los tipo de alias son cuatro y son los siguientes:

  • Cmnd_Alias - define alias de comandos.
  • User_Alias - define alias de usuarios normales.
  • Runas_Alias - define alias de usuarios administradores o con privilegios.
  • Host_Alias - define alias de hosts o equipos.

El NOMBRE_DEL_ALIAS puede llevar letras, números o guión bajo ( _ ) y DEBE de comenzar con una letra mayúscula, se acostumbra a usarlos siempre en mayúsculas.

Los elementos del alias varian dependiendo del tipo de alias, asi que veámoslos por partes asi como varios ejemplos para que comience a quedar claro todo esto.


Cmnd_Alias

Definen uno o más comandos y otros alias de comandos que podrán ser utilizados después en alias de usuarios. Ejemplos:


Cmnd_Alias WEB = /usr/sbin/apachectl, /usr/sbin/httpd, sudoedit /etc/httpd/

Indica que a quien se le aplique el alias WEB podrá ejecutar los comandos apachectl, httpd y editar todo lo que este debajo del directorio /etc/httpd/, nótese que debe de terminar con '/' cuando se indican directorios. También, la ruta completa a los comandos debe ser indicada.


Cmnd_Alias APAGAR = /usr/bin/shutdown -h 23\:00

Al usuario que se le asigne el alias APAGAR podrá hacer uso del comando 'shutdown' exactamente con los parámetros como están indicados, es decir apagar -h (halt) el equipo a las 23:00 horas. Nótese que es necesario escapar el signo ':', asi como los símbolos ' : , = \


Cmnd_Alias NET_ADMIN = /sbin/ifconfig, /sbin/iptables, WEB

NET_ADMIN es un alias con los comandos de configuración de interfaces de red ifconfig y de firewall iptables, pero además le agregamos un alias previamente definido que es WEB, asi que a quien se le asigne este alias podrá hacer uso de los comandos del alias WEB.


Cmnd_Alias TODO_BIN = /usr/bin/, !/usr/bin/rpm

A quien se le asigne este alias podrá ejecutar todos los comandos que estén dentro del directorio /usr/bin/ menos el comando 'rpm' ubicado en el mismo directorio. NOTA IMPORTANTE: este tipo de alias con un permiso muy amplios menos '!' algo, generalmente no son una buena idea, ya que comandos nuevos que se añadan después a ese directorio también podrán ser ejecutados, es mejor siempre definir específicamente lo que se requiera.


User_Alias

Definen a uno o más usuarios, grupos del sistema (indicados con %), grupos de red (netgroups indicados con +) u otros alias de usuarios. Ejemplos:


User_Alias MYSQL_USERS = andy, marce, juan, %mysql

Indica que al alias MYSQL_USERS pertenecen los usuarios indicados individualmente más los usuarios que formen parte del grupo 'mysql'.


User_Alias ADMIN = sergio, ana

'sergio' y 'ana' pertenecen al alias ADMIN.


User_Alias TODOS = ALL, !samuel, !david

Aqui encontramos algo nuevo, definimos el alias de usuario TODOS que al poner como elemento la palabra reservada 'ALL' abarcaría a todos los usuarios del sistema, pero no deseamos a dos de ellos, asi que negamos con '!', que serían los usuarios 'samuel' y 'david'. Es decir, todos los usuarios menos esos dos. NOTA IMPORTANTE: este tipo de alias con un permiso muy amplios menos '!' algo, generalmente no son una buena idea, ya que usuarios nuevos que se añadan después al sistema también serán considerados como ALL, es mejor siempre definir específicamente a los usuarios que se requieran. ALL es válido en todos los tipos de alias.


User_Alias OPERADORES = ADMIN, alejandra

Los del alias ADMIN más el usuario 'alejandra'.


Runas_Alias

Funciona exactamente igual que User_Alias, la única diferencia es que es posible usar el ID del usario UID con el caracter '#'.

Runas_Alias OPERADORES = #501, fabian

Al alias OPERADORES pertenecen el usuario con UID 501 y el usuario 'fabian'


Host_Alias

Definen uno o más equipos u otros alias de host. Los equipos pueden indicarse por su nombre (si se encuentra en /etc/hosts) por nombre de dominio, si existe un resolvedor de dominios, por dirección IP, por dirección IP con máscara de red. Ejemplos:


Host_Alias LANS = 192.168.0.0/24, 192.168.0.1/255.255.255.0

El alias LANS define todos los equipos de las redes locales.


Host_Alias WEBSERVERS = 172.16.0.21, web1 : DBSERVERS = 192.168.100.10, dataserver

Se define dos alias en el mismo renglón: WEBSERVERS y DBSERVERS con sus respectivas listas de elementos, el separador ':' es válido en cualquier definición de tipo de alias.


Opciones (defaults)

Las opciones o defaults permiten definir ciertas características de comportamiento para los alias previamente creados, para usuarios, usuarios privilegiados, para equipos o de manera global para todos. No es necesario definir opciones o defaults, sudo ya tiene establecidas el valor de cada uno, y es posible conocerlas a través de sudo -V (ver en la sección sudo de este tutorial).

Sin embargo, la potencia de sudo está en su alta granularidad de configuración, asi que es importante conocer como establecer opciones espécificas.

Las opciones o defaults es posible establecerlos en cuatro niveles de uso:

  • De manera global, afecta a todos
  • Por usuario
  • Por usuario privilegiado
  • Por equipo (host)

Se usa la palabra reservada 'Defaults' para establecer las opciones y dependiendo del nivel que deseamos afectar su sintaxis es la siguiente:

  • Global: Defaults opcion1, opcion2 ...
  • Usuario: Defaults:usuario opcion1, opcion2 ...
  • Usuario Privilegiado: Defaults>usuario opcion1, opcion2 ...
  • Equipo: Defaults@equipo opcion1, opcion2 ...

La lista de opciones es algo extensa, pueden consultarse en las páginas del manual (man sudoers) o en el excelente manual sobre sudo del sitio web de www.rpublica.net http://www.rpublica.net/sudo/indice.html#defaults, está en español y define muy claramente lo que significa cada opción. En este tutorial de LinuxTotal.com.mx me concretaré a ejemplificar varios ejemplos del uso de establecer opciones.

Los defaults los divide el manual (man sudoers) en cuatro: flags o booleanos, enteros, cadenas y listas. Veamos entonces algunos ejemplos de uso para cada uno de ellos:


flags o booleanos

Generalemente se usan de manera global, simplemente se indica la opción y se establece a 'on' para desactivarla 'off' se antepone el símbolo '!' a la opción. Es necesario consultar el manual para saber el valor por defecto 'on' o 'off' para saber si realmente necesitamos invocarla o no.


Defaults mail_always

Establece a 'on' la opción 'mail_always' que enviara un correo avisando cada vez que un usuario utiliza sudo, a la vez, este opción requiere que 'mailto_user' este establecida.


Defaults !authenticate, log_host

Desactiva 'off' el default 'authenticate' que por defecto esta activado 'on' e indica que todos los usuarios que usen sudo deben identificarse con su contraseña, obviamente esto es un ejemplo y sería una pésima idea usarlo realmente, ya que ningún usuario necesitaria autenticarse, esto es porque estamos usando Defaults de manera global. La segunda opción 'log_host' que por defecto está en 'off' la activamos y bitacoriza el nombre del host cuando se usa un archivo (en vez de syslog) como bitácora de sudo.


Defaults:ana !authenticate

Aqui se aprecia algo más lógico, usamos opciones por usuario en vez de global, indicando que el usuario 'ana' no requerira auténticarse. Pero todos los demás si.


Defaults>ADMIN rootpw

Opciones para usuarios privilegiados, en vez de usar una lista de usuarios, usamos un alias 'ADMIN' que se supone fue previamente definido, y establecemos en 'on' la opción 'rootpw' que indica a sudo que los usuarios en el alias 'ADMIN' deberán usar la contraseña de 'root' en vez de la propia.


Enteros

Tal como su nombre lo indica, manejan valores de números enteros en sus opciones, que deben entonces usarse como opción = valor.


Defaults:fernanda, regina passwd_tries = 1, passwd_timeout = 1

Ejemplo donde se aprecia el uso de opciones con valores enteros. En este caso se establecen opciones para los usuarios 'fernanda' y 'regina' solamente, que solo tendrán una oportunidad de ingresar la contraseña correcta 'passwd_tries' el valor por defecto es de 3 y tendrán un minuto para ingresarla 'passwd_timeout' el valor por defecto son 5 minutos.

La mayoría de las opciones de tiempo o de intentos, al establecerlas con un valor igual a cero entonces queda ilimitado la opción.


Defaults@webserver umask = 011

Se establecen opciones solo para los usuarios que se conectan al servidor 'webserver' y el valor 'umask' indica que si mediante la ejecución del comando que se invoque por sudo es necesario crear archivos o diectorios, a estos se les aplicará la máscara de permisos indicada en el valor de la opción.


Cadenas

Son valores de opciones que indican mensajes, rutas de archivos, etc. Si hubiera espacios en el valor es necesario encerrar el valor entre comillas dobles (" ").


Defaults badpass_message = "Intenta de nuevo: "

Para todos los usuarios, cuando se equivoquen al ingresar la contraseña, es el mensaje que saldría. En este caso la opción por defecto es "Sorry: try again".


Listas

Permite establecer/eliminar variables de entorno propias de sudo. Los 'Defaults' para variables es de los menos usados en las configuraciones de sudo y ciertamente de los más confusos. Para entender como se aplican es más fácil si primero ejecutas como 'root' el comando sudo -V, y al final del listado encontrarás en mayúsculas las posibles variables de entorno que se pueden establecer o quitar y que vienen del shell.

Solo existen tres opciones de listas: env_check, env_delete y env_keep, las listas pueden ser remplazadas con '=', añadidas con '+=', eliminadas con '-=' o deshabilitadas con '!'. Con un par de ejemplos quedará más claro.


Defaults env_delete -= HOSTNAME

Elimina la variable de entorno 'HOSTNAME', (pero preserva todas las demás que hubiera) y comandos que se ejecuten bajo sudo y que requieran de esta variable no la tendrían disponible.


Defaults env_reset

Defaults env_check += DISPLAY, PS1

La primera opción 'env_reset' reinicializa las variables de entorno que sudo utilizará o tendrá disponibles, y solo quedan disponibles LOGNAME, SHELL, USER y USERNAME. La siguiente línea indica que agregue (+=) a lo anterior, también la variable de entorno DISPLAY a su valor establecido antes del reset.


Reglas de acceso

Aunque no es obligatorio declarar alias, ni opciones (defaults), y de hecho tampoco reglas de acceso, pues el archivo /etc/sudoers no tendría ninguna razón de ser si no se crean reglas de acceso. De hecho podríamos concretarnos a crear solamente reglas de acceso, sin opciones ni alias y podría funcionar todo muy bien.

Las reglas de acceso definen que usuarios ejecutan que comandos bajo que usuario y en que equipos. La mejor y (según yo, única manera) de entender y aprender a configurar sudoers es con ejemplos, asi que directo al grano:


usuario host = comando1, comando2, ... comandoN

Sintaxis básica, 'usuario' puede ser un usuario, un alias de usuario o un grupo (indicado por %), 'host' puede ser ALL cualquier equipo, un solo equipo, un alias de equipo, una dirección IP o una definición de red IP/máscara, 'comandox' es cualquier comando indicado con su ruta completa. Si se termina en '/' como en /etc/http/ entonces indica todos los archivos dentro de ese directorio.


daniela ALL = /sbin/iptables

Usuario 'daniela' en cualquier host o equipo puede utiliar iptables.


ADMIN ALL = ALL

Los usuarios definifos en el alias 'ADMIN' desde cualquier host pueden ejecutar cualquier comando.


%gerentes dbserver = (director) /usr/facturacion, (root) /var/log/*

Un ejemplo más detallado. Los usuarios que pertenezcan al grupo del sistema llamado 'gerentes' pueden en el equipo llamado 'dbserver' ejecutar como si fueran el usuario 'director' la aplicación llamada 'facturacion', además como usuarios 'root' pueden ver el contendido de los archivos que contenga el directorio /var/log.


Lo anterior intoduce algo nuevo, que en la lista de comandos es posible indicar bajo que usuario se debe ejecutar el permiso. Por defecto es el usuario 'root', pero no siempre tener que asi. Además la lista 'hereda' la primera definición de usuario que se indica entre paréntesis ( ), por eso si se tiene más de alguno hay que cambiar de usuario en el comando conveniente, el ejemplo anterior también sería válido de la siguiente manera:

%gerentes dbserver = /var/log/*, (director) /usr/facturacion

No es necesario indicar (root) ya que es el usuario bajo el cual se ejecutan los comandos por defecto. También es válido usar (ALL) para indicar bajo cualquier usuario. El ejemplo siguiente da permisos absolutos.


sergio ALL = (ALL) ALL

Se establece permiso para el usuario 'sergio' en cualquier host, ejecutar cualquier comando de cualquier usuario, por supuesto incluyendo los de root.


SUPERVISORES PRODUCCION = OPERACION

Una regala formada solo por alias. En el alias de usuario 'SUPERVISORES' los usuarios que esten indicados en ese alias, tendrán permiso en los equipos definidos en el alias de host 'PRODUCCION', de ejecutar los comandos definidos o listados en el alias de comandos 'OPERACION'.


En este último ejemplo se aprecia lo últil que pueden ser los alias, ya que una vez definida la regla, solo debemos agregar o eliminar elementos de las listas de alias definidos previamente. Es decir, se agrega un equipo más a la red, se añade al alias 'PRODUCCION', un usuario renuncia a la empresa, alteramos el alias 'SUPERVISORES' eliminándolo de la lista, etc.

checo ALL = /usr/bin/passwd *, !/usr/bin/passwd root

Este es un ejemplo muy interesante de la potencia y flexibilidad . Al usuario 'checo', desde cualquier equipo, tiene permiso de cambiar la contraseña de cualquier usuario (usando el comando 'passwd'), excepto '!' la contraseña del usuario 'root'. Lo anterior se logra mediante el uso de argumentos en los comandos. En el primer ejemplo '/usr/bin/passwd *' el asterisco indica una expansión de comodin (wildcard) que indica cualquier argumento, es decir, cualquier usuario. En el segundo caso '!/usr/bin/passwd root', si indica un argumento específico 'root', y la '!' como ya se sabe indica negación, negando entonces el permiso a cambiar la contraseña de root.


Cuando se indica el comando sin argumentos: /sbin/iptables sudo lo interpreta como 'puede usar iptables con cualquiera de sus argumentos'.


mariajose ALL = "/sbin/lsmod"

Al estar entre comillas dobles un comando, entonces sudo lo interpreta como 'puede hacer uso del comando lsmod pero sin argumentos'. En este caso el usuario 'mariajose' podrá ver la lista de módulos del kernel, pero solo eso.


Tags (etiquetas de comandos)

Cuando se definen reglas, en la lista de comandos, estos pueden tener cero (como en los ejemplos anteriores) o más tags. Existen 6 de estas etiquetas o tags,


NOPASSWD Y PASSWD

Por defecto sudo requiere que cualquier usuario se identifique o auténtifique con su contraseña. Aprendimos en la sección de 'Opciones' o 'Defaults' que es posible indicar que un usuario o alias de usuario no requiera de autentificación. Pero el control granular propio de sudo, permite ir aun más lejos al indicar a nivel de comandos, cuáles requieren contraseña para su uso y cuáles no.


gerardo webserver = NOPASSWD: /bin/kill, /usr/bin/lprm, /etc/httpd/conf/

Usuario 'gerardo' en el equipo 'webserver' no requerira contraseña para los comandos listados. El tag se hereda, es decir no solo el primer elemento de la lista de comandos, sino los subsiguientes. Suponiendo que el último '/etc/httpd/conf/' elemento, que permite modificar cualquier archivo contenido en el directorio, si deseamos que use contraseña, lo siguiente lo conseguirá:

gerardo webserver = NOPASSWD: /bin/kill, /usr/bin/lprm, PASSWD: /etc/httpd/conf/

Aunque ya que solicitar contraseña es el default o defecto preestablecido, lo anterior también funcionará de la siguiente manera:

gerardo webserver = /etc/httpd/conf/, NOPASSWD: /bin/kill, /usr/bin/lprm,


NOEXEC Y EXEC

Este es un tag muy importante a considerar cuando sobre se otorgan permisos sobre programas que permiten escapes a shell (shell escape), como en el editor 'vi' que mediante el uso de '!' es posible ejecutar un comando en el shell sin salir de 'vi'. Con el tag NOEXEC se logra que esto no suceda, aunque no hay que tomarlo como un hecho, ya que siempre existe la posibilidad de vulnerabilidades no conocidas en los múltiples programas que utilizan escapes a shell. Al igual que los tags anteriores, el tag se hereda y se deshabilita con su tag contrario (EXEC), en caso de que en la lista de comandos hubiera varios comandos.

valeria ALL = NOEXEC: /usr/bin/vi


SETENV Y NOSETENV

Una de las múltiples opciones que pueden establecerse en la sección 'Defaults' u 'opciones' es la opción booleana o de flag 'setenv' que por defecto y para todos los usuarios esta establecida en 'off'. Esta opción si se activa por usuario (Defaults:sergio setenv) permitirá al usuario indicado cambiar el entorno de variables del usuario del cual tiene permisos de ejecutar comandos, y como generalmente este es 'root' pues es obvio que resulta bastante peligrosa esta opción. A nivel de lista de comandos, es posible entonces especificar el tag 'SETENV' a un solo comando o a una pequeña lista de estos y solo cuando se ejecuten estos se podrán alterar su entorno de variables. Es decir, en vez de establecerlo por usuario, sería mas conveniente establecerlo por comando a ejcutarse solamente.

ADMIN ALL = SETENV: /bin/date, NOSETENV ALL

A los usuarios definidos en el alias de usuario 'ADMIN' en cualquier host, pueden alterar las variables de entorno cuando ejecuten el comando 'date' (que puede ser útil por ejemplo para cambiar variables del tipo LOCALE), y cualquier otro comando, no tendrá esta opción al habilitar el tag contrario 'NOSETENV'. Y ya que este es el default, también sería válido de la siguiente manera y harían lo mismo:

ADMIN ALL = ALL, SETENV: /bin/date


ARCHIVO /ETC/SUDOERS DE EJEMPLO

Para concluir este manual, veamos un pequeño ejemplo de un archivo /etc/sudoers:

# ***********************
# LinuxTotal.com.mx, ejemplo de un archivo sudoers
# sergio.gonzalez.duran@gmail.com
# ***********************

# ***********************
# DEFINCION DE ALIAS
# ***********************

# administradores con todos los privilegios
User_Alias ADMINS = sergio, ana

# administradores de red - network operators
User_Alias NETOPS = marcela, andrea

# webmasters -
User_Alias WEBMAS = cristina, juan

# supervisores de producción (todos los del grupo de sistema supervisores)
User_Alias SUPPRO = samuel, %supervisores

# usuarios que pueden conectarse desde Internet
User_Alias INETUS = NETOPS, ADMINS, samuel

# servidores web
Host_Alias WEBSERVERS = 10.0.1.100, 10.0.1.101

# servidores de aplicaciones
Host_Alias APLICACIONES = WEBSERVERS, 10.0.1.102, 10.0.1.103, mailserver

# comandos de red permitidos
Cmnd_Alias REDCMDS = /sbin/ifconfig, /sbin/iptables

# comandos de apache
Cmnd_Alias APACHECMDS = /usr/sbin/apachectl, /sbin/service httpd *

# ***********************
# DEFINCION DE OPCIONES
# ***********************

# Los usuarios administradores, requieren autentificarse con la contraseña de 'root'
Defaults>ADMINS rootpw

# Para todos los usuarios, tienen hasta dos intentos para ingresar su contraseña y 3 minuto para que esta expire
Defaults passwd_tries = 4, passwd_timeout = 1

# Los usuarios que se conectan desde Internet, solo tienen una oportunidad y cero timeout lo que implica
# que cada comando que usen a través de sudo requerira siempre de autentificación.
Defaults:INETUS passwd_tries = 1, passwd_timeout = 0

# Máscara de directorios y archivos por default, para los que ejecuten sudo en los servidores web
Defaults@WEBSERVERS umask = 022

# ***********************
# DEFINCION DE REGLAS
# ***********************

# administradores todo se les permite en cualquier equipo (¡¡¡¡¡cuidado con esto en la vida real!!!!!
ADMINS ALL = (ALL) ALL

# administradores de red, en todos los equipos, los comandos de red
NETOPS ALL = REDCMDS

# webmasters, en los servidores web con los comandos indicados en apachecmds y además sin necesidad
# de contraseña acceder a las bítacoras de apache y reiniciar los servidores.
WEBMAS WEBSERVERS = APACHECMDS, NOPASSWD: /var/log/apache/, /sbin/reboot

# supervisores, pueden ejecutar los comandos indicados en los equipos indicados en el alias
# aplicaciones y además son ejecutados bajo el usuario apps.
SUPPRO APLICACIONES = NOEXEC: (apps) /usr/local/facturacion.exe, /usr/local/ventas.exe, /usr/local/nomina.exe

# no definidos por alias previos, sino directamente

# regina es de recursos humanos y puede cambiar contraseñas de cualquier usuario menos de root
regina ALL = /usr/bin/passwd *, !/usr/bin/passwd root

# david, puede apagar los equipos de aplicaciones
david APLICACIONES = /sbin/shutdown, /sbin/halt

# El equipo firewall de la red puede ser reiniciado (no apagado) por fernanda que es asistente de redes
fernanda firewall = /sbin/shutdown -r now

Referencias

Como siempre, la referencia más a la mano la tienes en las páginas de manual:

  • man sudo
  • man visudo
  • man sudoers

Y en los siguientes sitios encuentras información que complementa esta manual.

Fuente: www.linuxtotal.com.mx

4/13/2008


Evitar ejecución de forkbombs

Ultimamente han comenzado a circular las Fork Bombs, que no son otra cosa que codigos de programación, los cuales consumen recursos de nuestra PC, dejandola totalmente inutilizable, vamos a ver algunos ejemplos y luego distintas soluciones que podemos darle a este problema
.
Uno escrito con Perl:

perl -e "fork while fork"

Otro con BASH:
:(){ :|:& };:

Este ultimo es el mas conocido y que se ha puesto de moda. Y es una versión ofuscada de:

forkbomb () {
forkbomb | forkbomb &
}
forkbomb

Lo que hace, es una función recursiva que se va llamando a si misma dos veces, creando un bucle interminable y consumiendo toda la memoria de nuestro sistema hasta dejarlo inutilizable, por lo cual no nos queda otra alternativa que reiniciar nuestro sistema.
Para ejecutar este codigo no debemos estar logueados como root, por lo cual cualquier usuario normal lo puede ejecutar y saturar todos los recursos de nuestra PC.

¿COMO SOLUCIONARLO?

Existe un comando interno de BASH llamado ulimit
(para mayor explicacion sobre el comando: man ulimit)
La opcion -u en este comando, nos permite configurar el numero maximo de procesos que los usuarios pueden ejecutar por lo cual, de esta manera al llegar la fork bomb al limite de procesos, no puede sobrepasarlo por lo cual con un valor bien configurado no nos probocaria problemas en el sistema.
Para ello ejecutamos

$: ulimit -u 50
Esta solución seria suficiente para solucionar esto, pero al momento de reiniciar nuestro sistema esta configuración se pierde.
Otra alternativa seria añadirlo al archivo /etc/profile y a /etc/bash.bashrc
Para evitar que se ejecute en sesiones de login y no-login.
Pero la forma estandar de hacerlo es añadiendolo a /etc/security/limits.confNOTA: En todos los script de BASH, como los que veeremos a continuación, todo lo precedido por # se lee como comentario. Siguiendo con el tema en una shell ejecutamos:

$: sudo nano /etc/security/limits.conf

Ponemos nuestra constraseña de usuario y veeremos en pantalla algo como esto:


# /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
#
# 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
# - 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
# - rtprio - max realtime priority
#
#
##* soft core 0
% hard rss 10000
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
% - maxlogins 4
% hard nproc 50
# End of file

Añadimos una linea (en el ejemplo ya esta añadida), con los siguientes valores.

% hard nproc 50

Con esto limitamos a 50 el numero maximos de procesos que puede ejecutar el usuario.
Guardamos la configuracion (Ctrl + O) y salimos (Ctrl + X).
Bien, ya estaria hecho ahora solo basta reiniciar el PC.$ sudo rebootY listo, ya estamos protegidos contra las fork bombs.
¿Como probarlo?, tipeamos lo siguiente:

$ ulimit -a

Y tendremos una salida como esta


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

Vemos el valor [max user processes] establecido en 50 (50 procesos como maximo puede
ejecutar el usuario).
Por lo cual si somos valientes y nos animamos a probar: :(){ :|:& };: podemos ver que
no pasa absolutamente nada en nuestro sistema y no se cuelga. =)NOTA: Si al configurar el valor de max user processes en 50, reciben cada tanto un error como este: bash: fork: recurso temporalmente no disponible, esto es debido a que su usuario esta ejecutando mas de 50 procesos normalmente, por lo cual para no recivirlo recomiendo modificar el valor a un nivel mas alto, como puede ser 100 (o de acuerdo a la cantidad de procesos que ustedes ejecuten normalmente) pueden saberlo utilizando el comando top.

Fuente

4/12/2008


yes > config &

Este sera un post muy breve orientado a los principiantes en los sistemas GNU/Linux.
¿Alguna vez en un IRC alguien les dijo que tipeen yes > config &?, ¿qué es esto?.

Bien paso a explicar, este es un parecido a una fork bomb (aunque no tiene nada que ver con la funcion fork), se basa de tres partes, el comando en si (yes), la redireccion (>) y la ejecución en el background (&).

  • yes: produce una secuencia infinita de yes (si)
  • >: redirecciona la salida estándar (la terminal, en este caso)
  • config: la redirección va a parar a un archivo llamado config
  • &: ejecuta el proceso en el background (segundo plano, invisible a nuestros ojos).

Bien, como hemos visto yes, al producir una secuencia inifita de si mismo, sera redireccionado a un archivo llamado config, el cual sera ejecutado en el background invisible a los ojos del usuario. Este archivo, comenzara a crecer inmediatamente hasta colapsar la capacidad de almacenamiento quoteada para el usuario, y peor aun (si no estuviera quoteada), de la partición, en la cual fue ejecutada. No quedandole otro remedio, al usuario inexperto que reiniciar.

Veamos:

$: yes > config &
[1] 20711

Vemos que la consola nos devuelve la siguiente información, [ 1 ], este es el numero de job del proceso, osea, es un número natural, que identifica a el proceso que se esta ejecutando en el background, y el siguiente número 20711 es el PID, (Identificador del proceso), esta información es muy util, ya que al no poder enviarle una señal de interrupción desde el teclado, deberemos interrumpilo desde la línea de comandos. Para esto, en otra terminal escribimos:

$: pgrep yes
20711

Lo que hemos hecho es buscar el proceso yes, y este nos devuelve el numero de PID<, necesario para poder matarlo, y asi evitar que siga ejecutandose, asi que rapídamente en la shell escribimos:

$: kill 20711

Y listo!, ya hemos matado al proceso yes y detenido la ejecución de esta forkbomb.
Ahora, un dato extra para saber la cantidad que ocupo el archivo generado (config) y conocer realmente lo rapido que se propaga esta secuencia infinita de yes escribimos:

$: du -h /home/usuario/config
157M /home/usuario/config

Por supuesto, que debemos cambiar por la ruta (path) donde nosotros hemos ejecutado el comando, y donde se encuentra el archivo config, viendo esto, podemos decir que en mi caso (una ejecucion de 25 segundos aproximadamente), el archivo crecio de 0 a 157 Mb., osea a una velocidad increible.

Espero que esto le sirva a todos los novatos, y a los que estan un poco mas avanzados, que no sean tan estúpidos de hacerles ejecutar esto, ya que asi, los alejan cada vez mas del software libre.

Overclock_Orange
fmdlc.unix (–en–) gmail.com

Fuente

4/05/2008


Proteger servidor Gnu/Linux contra ataques de fuerza bruta

Por motivos de quejas, ver el artículo de forat en http://www.forat.info

2/29/2008


Seguridad en /proc

Si no conocen el directorio /proc, es mejor que tengan algunos conocimientos sobre él, pueden ver Descubriendo al directorio /proc como recomendación.

Seguridad en /proc

Opciones de seguridad en Linux a través de /proc (I)

Diversos parámetros de seguridad de las máquinas que ejecuten Linux pueden ser
controlados a través del sistema de archivos virtual /proc.

/proc es un pseudo-sistema de archivos, ya que en realidad ni él ni ninguno de
los archivos y directorios contenidos en su interior existen realmente. /proc
nos facilita una interfaz para acceder y, en algunos casos, modificar, algunas
estructuras de datos del núcleo del sistema operativo.

/proc está disponible en el sistema operativo Linux cuando el núcleo se ha
compilado con la opción CONFIG_PROC_FS=Y. También deberemos seleccionar la
opción CONFIG_SYSCTL=Y para poder modificar el valor de determinados
parámetros, como veremos más adelante. La mayoría de distribuciones incluyen
núcleos compilados con esta opción y, como regla general, es aconsejable
seleccionarla en el momento de recompilar el núcleo.

El sistema de archivos /proc puede montarse automáticamente en el momento de
iniciar el sistema (si así se indica en el archivo /etc/fstab). En el caso de
que sea necesario montarlo manualmente, debe utilizarse la siguiente orden:

mount -t proc proc /proc

Es aconsejable que /proc sea montado automáticamente al sistema y que el núcleo
siempre se compile para dar soporte a este pseudo- sistema de archivos. En caso
de no disponer del soporte, muchos programas de utilidad no funcionarán y no
podremos modificar en tiempo de ejecución algunos parámetros del núcleo del
sistema operativo. Muchos de estos parámetros que nos pueden interesar
modificar son muy importantes desde el punto de vista de seguridad.

Contenido de /proc:

Dentro del directorio /proc encontramos dos tipos básicos de información. En
primer lugar, para cada proceso activo existe un directorio. Dentro del
directorio de cada proceso hay diversos archivos así como un subdirectorio con
información específica del proceso (parámetros pasado en la línea de órdenes,
enlace al directorio actual del proceso, las variables de entorno dentro del
contexto del proceso, los descriptores de los archivos abiertos en el proceso,
mapa e información acerca de la utilización de la memoria...).

Adicionalmente, existen una serie de directorios con información acerca de los
diferentes módulos del sistema operativo. En el archivo proc.txt (disponible en
el directorio Documentation/filesystems del código fuente del núcleo de Linux)
hay información detallada de todo lo que podemos encontrar dentro de /proc.
Otro documento de interés es ip-sysctl.txt, disponible en el directorio
Documentation/networking del código fuente del núcleo de Linux.

No todos los parámetros existentes en /proc son modificables directamente por
el usuario. De hecho, la mayoría son valores de sólo lectura y otros son mucho
mejor controlados por el núcleo o mediante la utilización de los diversos
mandatos y herramientas existentes en el sistema.

/proc/sys/net/ipv4

Dentro de este directorio disponemos de una serie de archivos con los valores y
parámetros para el protocolo IPv4. Se trata de los valores directamente
utilizados por el núcleo del sistema operativo en las comunicaciones TCP/IP
basadas en el protocolo IPv4.

Para determinar el valor de uno de estos parámetros lo único que tenemos que
hacer es mirar su contenido. Por ejemplo:

$cat /proc/sys/net/ipv4/icmp_echo_ignore_all
0

nos muestra que actualmente el sistema operativo tiene asignado el valor 0
(desactivado) al parámetro ICMP_ECHO_IGNORE_ALL.

El usuario root del sistema tiene el privilegio de modificar el valor de estas
variables:

# echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
# cat /proc/sys/net/ipv4/icmp_echo_ignore_all
1

Otra forma de configurar los valores es utilizando la utilidad sysctl.
Utilizando el ejemplo anterior, para determinar el valor debemos
utilizar:

$ sysctl net.ipv4.icmp_echo_ignore_all
net.ipv4.icmp_echo_ignore_all = 0

y para establecer el valor:

# sysctl -w net.ipv4.icmp_echo_ignore_all=1
net.ipv4.icmp_echo_ignore_all = 0

Ambas formas son equivalentes y podemos utilizar aquella con la que nos
encontremos más cómodos.

Una última forma de modificar los valores de los parámetros, de forma que estos
se mantengan incluso después de reiniciar el sistema es a través del archivo /
etc/sysctl.conf. Podemos obtener más detalles del formato de este archivo
ejecutando

man systcl.conf

Si se modifica el archivo /etc/sysctl.conf, los parámetros sólo se activarán la
próxima vez que se reinicie la máquina o bien después de reiniciar el soporte
de red, ejectuando

/etc/rc.d/init.d/network restart

Continuamos con la descripción de los parámetros de seguridad de las máquinas
que ejecutan Linux con el sistema de archivos virtual /proc. Los parámetros que
vamos a ver a continuación muestran como podemos controlar la forma en que un
sistema actúa en determinadas circunstancias. Estos parámetros nos van a ayudar
a fortalecer la seguridad del sistema operativo. Estos parámetros son un
complemento a las medidas de protección perimétricas, como pueden ser los
cortafuegos.

Mediante /proc no sólo podemos cambiar estos parámetros. Hay otras muchas cosas
interesantes que podemos hacer, como por ejemplo mejorar el rendimiento del
sistema de archivos, modificar la forma en que el sistema gestiona la memoria
virtual, incrementar el número máximo de archivos abiertos de forma simultánea
y otros cambios. Los lectoresinteresados pueden encontrar información al
respecto en la documentación que acompaña al código fuente del núcleo de Linux.

Todos los mandatos que indicamos a continuación deben ser ejecutados por el
usuario root.


Control del protocolo ICMP

- -Ignorar las peticiones de repuesta a ping

Dependiendo de la configuración de la red, puede ser interesante configurar el
sistema para que éste no responda cuando recibe un ping (mensaje ECHO del
protocolo ICMP). De esta forma, puede ser un poco más difícil que un atacante
descubra si el sistema está conectado a la red.

Para desactivar las respuesta de forma temporal:

# sysctl -w net.ipv4.icmp_echo_ignore_all=1

y para desactivarla de forma permanente, editar el archivo /etc/sysctl.conf y
añadir las líneas

net.ipv4.icmp_echo_ignore_all = 1

(Nota= En los siguientes parámetros, si se desea realizar el cambio de forma
permanente deberá modificarse igualmente el archivo /etc/sysctl.conf, tal como
hemos hecho para este parámetro).


No atender a las peticiones enviadas mediante broadcast

Cuando una máquina envía un paquete a la dirección de broadcast (por ejemplo,
192.168.1.255), éste es entregado a todas las máquinas existentes en la red
local. A continuación, todas las máquinas deben enviar un mensaje ECHO del
protocolo ICMP. Esto puede provocar una congestión de la red, a la vez que
permite determinar que sistemas están activos en la red.

Para desactivar la recepción de paquetes enviados a la dirección de broadcast:

# sysctl -w net.ipv4.icmp_echo_ignore_broadcasts = 1


Protección ante mensajes de error mal formateados

Es posible que una red se transmitan mensajes de error mal formateados. Para
evitar que éstos sean procesados por el sistema:

# sysctl -w net.ipv4.icmp_ignore_bogus_error_responses = 1


Deshabilitar la aceptación de redirecciones

Cuando el ordenador utiliza una ruta extinta o no-óptima para enviar un paquete
a un destino particular, los routers por donde circula el paquete envían al
origen un mensaje de redirección del protocolo ICMP para informar de la ruta
correcta a utilizar en el futuro.

Si un atacante tiene la capacidad de enviar mensajes de redirección puede
modificar las tablas de direccionamiento del ordenador, haciendo por ejemplo
que todo el tráfico fluya a través de una vía concreta.

Para evitar el proceso de estos mensajes en el sistema:

# sysctl -w net.ipv4.conf.all.accept_redirects = 0
# sysctl -w net.ipv4.conf.default.accept_redirects = 0


Protección contra ataques DoS de inundación SYN

El ataque de denegación de servicio (DoS) por inundación SYN ("SYN Flood")
consigue consumir todos los recursos de la máquina, haciendo que sea necesario
reiniciarla para volver a funcionar con normalidad.

Cada vez que se realiza una conexión TCP/IP existe una negociación de tres
pasos:

1. El cliente envía un paquete (paquete 1) al servidor con el bit SYN activado
y permanece a la escucha.
2. El servidor responde al cliente con un paquete de confirmación (paquete 2) y
permanece a la escucha.
3. El cliente envía un tercer paquete (paquete 3) que consolida la conexión.


La información recibida en el paquete 1 se conserva dentro de una cola para que
pueda ser comparada con los datos recibidos en el paquete 3 y dar por
establecida la conexión. Esta cola es de un tamaño limitado y tiene un tiempo
de latencia muy elevado.


El ataque de inundación SYN consiste en llenar esa cola, mediante el envío de
un gran número de paquetes 1 y nunca respondiendo con un paquete 3. En el
momento en que se llena la cola, el sistema es incapaz de atender cualquier
otra petición de conexión que reciba.

La protección contra este ataque consiste en añadir información en el paquete
2, de forma que no sea necesaria conservar en el servidor ningún dato sobre el
cliente.

Para activar esta protección:

# sysctl -w net.ipv4.tcp_syncookies = 1

Con este valor, el sistema utilizará el método de incluir la información en el
paquete 2 siempre que la cola de paquetes por procesar esté saturada.


Protección contra direcciones IP no válidas

Esta protección permite que la máquina no pueda utilizarse para el envío de
paquetes con direcciones IP no válidas. Este tipo de paquetes son habitualmente
enviados cuando la máquina está intentando realizar una acción potencialmente
ilegítima, como puede ser la suplantación de una conexión o el envío de
paquetes en un ataque de denegación de servicio.
Para activar esta protección:

# sysctl -w net.ipv4.conf.all.rp_filter = 2
# sysctl -w net.ipv4.conf.default.rp_filter = 2

El valor de los parámetros puede ser 0 (valor por omisión, no realizar ninguna
comprobación), 1 (rechazar únicamente las suplantaciones
evidentes) y 2 (realizar una comprobación exhaustiva). Aconsejamos seleccionar
la opción de comprobación exhaustiva.

Esta opción no debe utilizarse en aquellos sistemas que actúen como cortafuegos
o routers.


Redireccionamiento IP

El redireccionamiento IP es que en un sistema con diversos interfaces activos,
se acepten paquetes en un interfaz con destino al otro. Si la opción de
rediccionamiento está activa, la máquina podrá actuar como un router para el
tráfico entre las redes existentes de cada uno de los interfaces.

Únicamente aquellos sistemas que actúan como cortafuegos o routers o bien en
circunstancias muy especiales deberían tener esta opción activa.

Para verificar que se encuentra desactivada:

# sysctl -w net.ipv4.ip_forward = 0

Tal como hemos indicado anteriormente, en caso de activar con el valor 1 esta
opción, también deberemos modificar el valor de net.ip4.conf.all.rp_filter y
net.ipv4.conf.default.rp_filter.


Control de rutas

Habitualmente un sistema no tiene ningún control sobre la ruta utilizada por
los paquetes en su camino hacia su destino. El protocolo TCP/IP permite
establecer la ruta exacta a seguir. Excepto en circunstancias muy especiales,
este soporte deberá ser desactivado para evitar que un atacante pueda utilizar
un sistema concreto como paso para saltarse las
protecciones establecidas en el tráfico.

Para desactivar esta opción:

# sysctl -w net.ipv4.conf.all.accept_source_route = 0
# sysctl -w net.ipv4.conf.default.accept_source_route = 0


Registro de actividades sospechosas

Un último valor de interés nos permite registrar en los archivos de actividad
del sistema aquellas situaciones potencialmente sospechosas:


intento de envío de paquetes con dirección no válida, paquetes con cambio de
rutas y otras situaciones similares.

Se trata de una serie de situaciones que en un funcionamiento normal de la red
no pueden producirse en ninguna circunstancia. Un ejemplo puede ser la
recepción de un paquete a través de un interfaz Ethernet con dirección origen
igual a 127.0.0.1

Para activar el registro de esta actividad:

# sysctl -w net.ipv4.conf.all.log_martians = 1
# sysctl -w net.ipv4.conf.default.log_martians = 1

Fuentes:
http://www.govannom.org/seguridad/protect/seg_proc_i.txt