No inicies sesión como administrador

Utiliza RunAS

Un error muy común a la hora de iniciar sesión en un equipo es el hacerlo con un usuario con privilegios de administrador. La causa suele estar en el deseo de poder controlar con estos privilegios el equipo, para poder así hacer todo lo que queramos, sin limitaciones impuestas por una sesión de un usuario con privilegios limitados. Esto es un enfoque erróneo, desde el punto de vista de seguridad. En este artículo veremos porqué es un error y cómo podemos evitar esta práctica sin por ello dejar de poder realizar nuestro trabajo de administración.

El error de iniciar sesión como administrador

¿Por qué no iniciar sesión con un usuario administrador? Por motivos de seguridad, seguridad tanto en la precisión de nuestros movimientos como en las posibilidades de sufrir un ataque de código malicioso.

Si tenemos que hacer una tarea que requiera disponer de privilegios administrativos, es mejor que seamos conscientes de que lo que estamos realizando requiere estos privilegios. Esto es, que si intentamos hacer algo con un usuario sin privilegios administrativos la operación nos sea denegada o que, directamente, tomemos las acciones necesarias para poder realizar la acción como administrador; de esta manera sabremos que estamos haciendo algo "serio" y encararemos la tarea de una manera más consciente, más meditada.

Si ejecutamos un adjunto de un correo que contiene un virus (esto que he dicho nunca debería pasar, pero...), el virus intentará hacer "sus cositas", tan simpáticas y bondadosas ellas; digo intentará porque el virus será lanzado con los privilegios del usuario que lo ha ejecutado y, si no nos hemos logado como administradores, el virus no podrá tomar acciones de veras dañinas con el sistema, al carecer de los privilegios necesarios como para, por ejemplo, escribir en el directorio de Windows, o en la rama del registro HKEY_LOCAL_MACHINE. Si el virus es ejecutado con un usuario administrador..., bueno, si este es el caso, con lo dicho anteriormente, está diáfano que el virus podrá hacer, sencillamente, lo que se le antoje. Esto que decimos de los virus lo podemos decir de los troyanos, spyware, etc.

Una última consideración. Si esto que hemos dicho es grave en un equipo de usuario ¿qué pasa con los servidores? Un servidor es mejor que no tenga usuario logado, pero en muchas ocasiones estamos obligados a que haya un usuario logado, por culpa de algún software que lo requiera, por ejemplo. Es una práctica demasiado común dejar estos servidores logados con un usuario administrador ¡¡incluso con el propio administrador del dominio!! ¿Qué pasa si un código malintencionado se ejecuta en ese servidor? ¿Qué pasa si se cuela un troyano? ¡¡Privilegios de administrador del dominio para el troyano/virus/etc.!! ¡¡¡No, no, no, no, noooooooo!!! Definitivamente no es buena idea logarse como administrador....

¿Cómo realizar acciones administrativas sin logarme como administrador?

El problema de seguridad que se deriva de iniciar sesión como administrador no es únicamente de Windows, es algo inherente a los propios sistemas operativos. De ahí el que se incluya en ellos mecanismos para poder lanzar procesos con otras credenciales diferentes a las del usuario que está logado. Estas utilidades permiten lanzar los procesos con cualquier usuario, no es requerido que se lancen con usuarios administradores, pero su mayor utilidad es, precisamente, cuando se ejecutan para lanzar los procesos como usuario administrador. Todo buen curso de administración de un sistema operativo recomendará que no se inicie sesión como administrador nunca, si no que se haga como usuario limitado y se haga uso de estas utilidades cuando se requiera realizar una acción administrativa. En Unix/Linux usaremos SU, en Windows 2000/XP/2003 usaremos RunAs.exe.

RunAs.exe

RunAs nos permite, como vimos anteriormente, lanzar un programa como otro usuario distinto al que tiene iniciada la sesión. con él podremos administrar Windows, Active Directory, etc., sin necesidad de tener iniciada una sesión de administrador.

Sintaxis

La sintaxis completa de RunAs la tenemos en la ayuda; si queremos saberla basta con consultar en esta. Aquí sólo vamos a señalar la sintaxis básica para nuestros propósitos. Así pues, diremos que para usar RunAs lo haremos de la siguiente manera:

runas /user:{[dominio_o_equipo\]usuario | usuario[@dominio]} [/savecred | /savedcred] <ejecutable parámetros>

Donde:

/user:{[dominio_o_equipo\]usuario | usuario[@dominio]}: requerido; es el nombre del usuario con el que lanzaremos el ejecutable. El nombre puede estar expresado como Down-Level Logon Name (dominio\usuario) o como User Principal Name (usuario@dominio). Los dos ejemplos siguientes se refieren al mismo usuario:

/user:moria\balrog
/user:balrog@moria.mordor.org

/savecred o /savedcred: opcional; indica que se guarden las credenciales una vez suministradas. Es decir, sólo se nos pedirá que entremos la contraseña del usuario que lanza el ejecutable la primera vez que usemos RunAs con /savecred para lanzar el ejecutable; no sólo eso, si no que a partir de entonces todo ejecutable que lanzado con RunaAs con ese usuario no necesitará que se entre la contraseña.Por desgracia, este parámetro no está disponible en Windows 2000 ni en Windows XP Home, sólo en Windows XP Pro o Windows Server 2003. Si el sistema está en español la ayuda referencia este parámetro como /savedcred, si el sistema está en inglés lo referencia como /savecred; funciona de las dos maneras en los dos idiomas.

<ejecutable - parámetros>: requerido; es el ejecutable que se lanza, puede ir o no con su ruta, dependiendo desde dónde se lanza RunAs o de si está en el Path de sistema o usuario. Si se necesita que lleve parámetros se pondrán después del nombre del ejecutable tras un espacio. En el caso de que lleve parámetros o que en la ruta\nombre aparezca algún espacio, será necesario que encerremos el conjunto entre comillas. Se pueden utilizar variables de entorno, encerrado el nombre entre tantos por ciento (%). En ocasiones es necesario que los parámetros estén encerrados entre comillas (una ruta que tenga espacios, por ejemplo), en estos casos las comillas deberán ser escritas quitándoles el significado con slash invertido (\); por ejemplo:

runas /user:dominio\administrador "%SystemRoot%\explorer.exe /e, \"c:\Archivos de Isengard\""

Ejemplos de RunAs

En este caso lanzamos el programa "Bola de fuego.exe" del usuario gandalf del domino comunidad (expresado como DLLN); la ruta del ejecutable la construimos utilizando la variable de entorno ProgramFiles.

runas /user:comunidad\gandalf "%ProgramFiles%\LOTR\Conjuros\Bola de fuego.exe"

En este otro ejemplo, lanzamos el programa palantir.exe con el parámetro /informar_sauron con la cuenta del usuario saruman del dominio isengard.mordor.org, expresado como UPN. El programa no incluye ruta pues se supone que está en el Path.

runas /user:saruman@isengard.mordor.org /savecred "palantir.exe /informar_sauron"

En este último ejemplo se lanza el programa comer.exe con el usuario local pippin (al no llevar nombre de dominio se asume que es la máquina local); el programa está en el Path y al no haber ningún espacio (ni en la ruta ni por llevar algún parámetro) no está encerrado entre comillas.

runas /user:pippin /savecred comer.exe

Páginas 1 2 3 4

Siguiente