Archives for 

configuración

[Howto]: Como crear alias en GNU/Linux Debian

Los alias son comandos personalizados que se crean apartir de otros comandos mas generales, es decir, con los alias nos podemos ahorrar el esfuerzo de escribir un comando demasiado largo (incluyendo los parametros), cambiandolo por uno mucho mas corto. Esto se utiliza generalmente en operaciones y acciones que se suelen  repetir con determinada frecuencia, las cuales son demasiadas largas, un ejemplo cuando nos conectamos por ssh a un servidor  con determinada IP y puerto. Sin embargo,  una definicion mas formal:

En informática alias es una orden disponible en varios intérpretes de comandos tales como los shells de Unix, 4DOS/4NT y Windows PowerShell, que permite reemplazar una palabra o serie de palabras con otra. Su uso principal es el de abreviar órdenes o para añadir argumentos de forma predeterminada a una orden que se usa con mucha frecuencia. Los alias se mantienen hasta que se termina la sesión en la terminal, pero normalmente se suelen añadir en el fichero de configuración del intérprete de órdenes (~/.cshrc o /etc/csh.cshrc (aplicado a todo el sistema) para csh, o ~/.bashrc o si quieres aplicarlo a todo el sistema /etc/bashrc o /etc/bash.bashrc para bash) de forma que siempre están disponibles para todas las sesiones de terminal.

Como bien lo dice  la definicion, existen dos formas  para crear un alias:

  1. Alias temporal:  Solo funciona hasta que se cierre la terminal. Para crearlo es muy sencillo, la sintaxis debe ser: alias nombre=’comando’
  2. Si quisieramos crear un alias para conectarnos al servidorA hariamos lo siguiente:

    alias servidorA=’ssh usuario@127.0.0.1 -p 22′

    Ahora lo ejecutamos:

    De esta forma, quedaria nuestro alias creado, pero cuando la consola fuera cerrada, el alias desapareceria.

  3. Sin embargo podemos crear los alias de forma permantente para cualquier usuario,  para esto la sintaxis es igual, lo unico que debemos hacer es agregar el comando en el .bashrc  del usuario y agregar al alias:

nano /home/usuario/.bashrc y agregamos el alias

alias servidorA=’ssh usuario@127.0.0.1 -p 22′

Guardamos,  y listo solo nos queda probar el alias

De esta forma quedara listo nuestro alias.

Los alias son muy utiles para aquellos SySAdmin que diariamente tiene que administrar diferentes tipos de servidores, y realizar las mismas tareas en cada uno de ellos.

DirBuster: Descubriendo directorios y archivos ocultos en servidores web, usando fuerza bruta

Dirbuster es una herramienta desarrollada en JAVA que nos permite encontrar aquellos directorios y archivos que  se encuentren en los servidores WEB y que no tengan los permisos asignados correctamente,  haciendo uso de la tan famosa tecnica “FUERZA BRUTA”.  Aunque esta tecnica  usada por dirbuster no es nueva (ya que existen algunos programas similares, como nikto), hay algunas caracteristicas que hacen a Dirbuster una interesante herramienta:

  • Multiproceso ( en las pruebas de hasta 6000 peticiones por segundo)
  • soporte https
  • capaz de escanear más profundo en los directorios que encuentre
  • También puede trabajar en modo de fuerza bruta con diccionario
  • encabezados HTTP personalizad
  • análisis de contenido cuando las solicitudes no vienen con una respuesta de 200 de cabecera
  • extensión de archivo personalizado
  • la configuración de rendimiento puede ser modificada mientras el programa se está ejecutando
  • básica, implícita y admite la autenticación NTLM
  • La interfaz GUI

Pueden descargar la aplicacion desde aca.

Despues de haberlo descargado, y extraido, lo podemos ejecutar de la siguiente forma (cabe resaltar que se necesita JAVA).

cd DirBuster-0.12
java -jar DirBuster-0.12.jar

si todo ha salido bien, aparecera la GUI de la aplicacion:

Ahora  digitamos la url del objetivo e igualmente seleccionamos los parametros que nosotros deseemos, como el metodo ya sea get, head o ambos. Escogemos uno  de los diccionarios que trae la aplicacion, ajustamos algunos parametros adicionales y por ultimo damos click en start.

Inmediatamente saldra una nueva pantalla con todos los resultados que va obteniendo la aplicacion.  Como ven es muy sencillo  manejar la aplicacion, y da magnificos resultados, la recomiendo!.

PWNAT – Herramienta cliente de comunicación NAT to NAT

PWNAT, es una herramienta que permite a un sin numero de clientes que se encuentren detrás de un NAT comunicarse con un server detrás de un NAT diferente, sin un puerto de reenvío y sin una configuración de DMZ en el router para comunicarse directamente con los demás.

En resumen, PWNAT funciona como un proxy detrás de un NAT, no hay middle man, no hay proxies, ni terceras partes involucradas en el proceso. Lo más importante es que el cliente se pueda conectar a cualquier host o puerto en cualquier host o puerto remoto.

PWNAT esta basado en el software UDP tunneling hecho por Daniel Meekins, udptunnel y chownat.

PWNAT trabaja en la mayoria de los sistemas operativos *nix.

Para descargar esta herramienta este es el enlace

SINOPSIS

uso: ./pwnat <-s | -c> <args>

  -c    modo Cliente
    <args>: [local ip] <local port> <proxy host> [proxy port (def:2222)] <remote host> <remote port>

  -s    Modo servidor
    <args>: [local ip] [proxy port (def:2222)] [[allowed host]:[allowed port] ...]

  -6    use IPv6
  -v    show debug output (up to 2)
  -h    show help and exit

Fuente

Seguridad en transacciones de SAP

“She was more like a beauty queen from a movie scene”

Tengo que aceptar que esta canción me recuerda a Campus Party, las pocas veces que la escucho lo hago pero en la versión acústica que tiene Chris Cornell.  Por lo mismo os la recomiendo.

Antes que nada debo disculparme enormemente con las personas que nos leen puesto que llevo mucho tiempo sin escribir en RinconInformatico.NET y sin querer he terminado por acostumbrado a no hacerlo, y eso es un grave error de mi parte.

Hoy quiero hablar un poco de mi trabajo.

SAP como todo (¿Gran?) sistema de administración de empresas (ERP) maneja autorizaciones para los usuarios y esta es una buena parte de la seguridad como tal.  Como bien definida por la etimología de la palabra:

Autorización es la capacidad que se le otorga a un individuo para realizar una actividad.

Las autorizaciones en SAP se manejan por medio de ROLES y dentro de los roles encontramos los PERFILES, en estos perfiles de usuario se almacenan las AUTORIZACIONES y son estas las que configuramos por medio de OBJETOS de AUTORIZACION.

¿Claro?

Espero que sí.  Sin embargo y comenzando por lo pequeño… un objeto de autorización simplemente es un mecanismo usado para INSPECCIONAR los privilegios de un usuario para acceder a determinados datos o ejecutar determinados programas.

Es en los objetos de autorización donde se configuran las ACTIVIDADES permitidas a un usuario, para que modifique determinado campo o cambio una descripción:

Ejemplo 1:

El usuario A, desea cambiar la descripción de un material pues resulta que tiene un error gramatical, el objeto de autorización X controla las modificaciones sobre las descripciones en los textos de los materiales.  Por lo tanto el Usuario A debe tener a X en su ROL configurado de la manera adecuada para que le permita ejecutar el cambio.

¿Qué es un Rol?

El rol de un usuario es un contenedor de perfiles, y los perfiles a su vez (como antes lo indicábamos) son los que contienen a las autorizaciones, y estas son simplemente las configuraciones de los Objetos de autorización.  El Rol es lo que en las últimas versiones SAP a implementado con el fin de que la seguridad de accesos al sistema R/3 de SAP pueda ser administrada por una persona sin grandes conocimientos ni experiencia en este tipo de Sistemas de información.

¿Un usuario puede tener varios Roles?

Completamente, de hecho es lo recomendado para las cosas más genéricas, por ejemplo el permiso para imprimir.

¿Un Rol puede tener varios Perfiles?

No, solo hay un rol por perfil.

Entonces ¿Puede haber varias autorizaciones en un perfil?

Afirmativo.  Cada vez que ingresamos un objeto de autorización en un rol o perfil este crea una nueva autorización, con la configuración que se le de al objeto de autorización.

¿Puede darse ese caso?

Todo el tiempo:

Ejemplo 2:

El mismo usuario A quien tiene permiso de modificar descripciones de textos en los materiales de la empresa, NO debe tener acceso de modificación al rango de materiales 100-200 porque estos son materiales para pruebas de calidad y no es necesario, pero si debe tener acceso a la visualización de estos materiales.  Este tipo de permisos son administrados por el objeto Y el cual tiene la posibilidad de configurar la creación, modificación y la visualización sobre los materiales.  Lo que hace un administrador de accesos es agregar DOS objetos, uno que permita la modificación de los rangos que si tiene acceso y otro donde permita la visualización de todos los materiales.

En este caso tendríamos un Rol, un perfil, pero dos autorizaciones y por lo tanto dos objetos de autorización, iguales; pero de diferente configuración.

¿Puede llegar a ser complicado?

Mi experiencia me dice que sí.  Pues las recomendaciones de “los que saben” siempre es que los roles deben configurarse de manera GENERICA, por si alguien más requiere de estos permisos.  Sin embargo YO personalmente NO comparto esta teoría, puesto que la mayoría de las veces que se requiere restringir un acceso implica tener que modificar estos roles genéricos (Y lo que conlleva con ello, bien sea quitando acceso a TODOS lo que tengan dicho ROL u otorgando mas de los necesario a las mismos que tengan dicho rol) y terminar creando roles particulares.  Resultando en lo mismo que crear Roles particulares desde el principio.

Finalmente, los programas estándar de SAP tienen definida las peticiones de información a los roles de los usuarios, a nivel programacional, es decir, en ABAP la sentencia que verifica las autorizaciones es:

Donde “Z_TCODE” es el nombre del objeto de autorización, ID es el campo que controla y FIELD es la actividad que permitida el usuario.

Esta es una explicación a groso modo y para que la entiendan las personas que no manejan SAP todos los días.  En un futuro si lo creo necesario podemos hablar de cómo se realizan las autorizaciones, es decir, un manual donde veamos paso por paso como asignar permisos en los usuarios de un sistema R/3.  Por ahora no lo creo necesario, pero puede llegar el caso.

Así funciona la seguridad en los accesos de SAP, no es ni más ni menos.

Como hoy para mi persona es un día especial, quería compartir estos pensamientos de un personaje de película, en español es llamada como “Nada es para Siempre”, es la parte final de dicha Historia y dice así:

Claro, ya estoy muy viejo para pescar bien.

Casi siempre voy a pescar solo.  Aunque me dicen que no lo haga.

Pero a solas, en la media luz de la cañada…toda la existencia parece esfumarse y quedan mis recuerdos…y los rumores del río y el ritmo en compás de 4…y la esperanza de que muerdan.

A la larga todos los paisajes se funden…atravesados por un río.

El río se formó del gran diluvio…y corre sobre las piedras del tiempo.

Sobre algunas piedras, hay gotas eternas.

Bajo las piedras, están las palabras.

Y algunas de las palabras son suyas.

El río me consuela.

Artículo enteramente dedicado al Mejor de Todos Los Tiempos a mi Papá, a Don Germán.

Instalación y configuración de un servidor ssh en Debian

Una de las herramientas indispensables para administrar los servidores es a través de SSH (Secure SHell). Pero antes, un poco de teoría.

Definición

“SSH (Secure SHell) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Permite manejar por completo la maquina mediante un intérprete de comandos, y también puede redirigir el tráfico de X para poder ejecutar programas gráficos si tenemos un Servidor X (en sistemas Unix y Windows) corriendo.

Además de la conexión a otros dispositivos, SSH nos permite copiar datos de forma segura (tanto ficheros sueltos como simular sesiones FTP cifradas), gestionar claves RSA para no escribir claves al conectar a los dispositivos y pasar los datos de cualquier otra aplicación por un canal seguro tunelizado mediante SSH” (Wikipedia).

Funcionamiento

El cliente inicia la conexión hacia un puerto predeterminado del servidor, en este caso el puerto reservado número 22. Establecida la conexión TCP los extremos se envían, en texto plano, sus identificadores de versión, para ver si la comunicación es posible entre ellos. De ser compatibles entre sí cambian a un modo de transferencia binaria durante el cual se identifican los interlocutores y se negocian los protocolos de cifrado y firma que se usarán.

Esta negociación de protocolos se lleva a cabo de tal manera que la información intercambiada entre cliente y servidor sólo puede ser descifrada por el destinatario legítimo de la misma, y sólo por él. Para ello al principio de esta fase el servidor envía al cliente su clave pública, para que el cliente la use para cifrar todos los mensajes siguientes hacia el servidor, haciéndolos sólo legibles para el propio servidor. Entonces el cliente genera una clave de cifrado para la sesión en curso, que envía cifrada al servidor junto con el algoritmo seleccionado, y a partir de este momento todo el tráfico entre cliente y servidor viaja cifrado y seguro.

Llegados a este punto el cliente y el servidor se han puesto de acuerdo en un cierto algoritmo de cifrado, han acordado una clave para su sesión, y el servidor se ha identificado ante el cliente con su clave pública RSA (u opcionalmente DSA, en la versión 2 del protocolo). Pero aún falta que el cliente se identifique ante el servidor, que deberá decidir entonces si deja o no acceder al cliente remoto. La identificación del cliente podrá ser mediante pareja de usuario y contraseña, rhost, rhost más identificación de máquina mediante clave RSA o simplemente mediante claves RSA o DSA.

De todos los mecanismos sólo nos interesan el primero y el último. En el primero, el servidor nos dará acceso siempre y cuando la pareja de usuario y contraseña introducida por el cliente sean los de un usuario válido en el sistema operativo del servidor, salvo restricciones adicionales. En la identificación por claves el cliente dispone, al igual que el servidor, de su propia pareja de claves, que envía al servidor durante la identificación. Si el servidor confía en el usuario cuya clave ha recibido, entonces le dará permiso de acceso.

A grandes rasgos el mecanismo de conexión y de identificación del protocolo SSH es sencillo, aunque conviene destacar un par de aspectos relevantes de cara al uso y configuración de los programas relacionados:

  • Las conexiones las inicia siempre el cliente hacia el puerto TCP número 22 del servidor.
  • Las versiones de los protocolos soportados por cliente y servidor deben coincidir, o la conexión no se llevará a cabo.
  • El servidor siempre necesita disponer de una pareja de claves, puesto que usa la clave pública para establecer la conexión segura con el cliente. El tipo de clave tiene que estar soportado en el cliente.
  • El cliente y el servidor deben tener algún algoritmo de cifrado en común, o la conexión no se establecerá.
  • Dependiendo de los mecanismos de identificación soportados por ambas partes, o exigidos por el servidor, la identificación podrá o no fallar.
  • Aún cuando haya un mecanismo de identificación soportado por ambas partes, el cliente deberá proporcionar credenciales válidas al servidor, bien sea una pareja de usuario y contraseña, bien una clave pública.

Al margen de todo lo anterior, el servidor del protocolo SSH, sshd podrá implementar restricciones adicionales de acceso, así como el propio sistema operativo donde ejecuta. Por ejemplo, no es infrecuente que sshd esté compilado con soporte de TCP-wrappers, que esté configurado para aceptar o rechazar el acceso a determinados usuarios o máquinas cliente, o simplemente que algún firewall intermedio no permita establecer la conexión.

Instalación y configuración inicial

1.-Abrir una terminal como root y escribir:

# Apt-get install openssh-server

2.-Cuando se termina de instalar viene con una configuración por default que debemos cambiar para tener una mejor seguridad para esto nos vamos al archivo /etc/ssh/sshd_config

# Vim /etc/ssh/sshd_config

El archivo es algo extenso solo se mencionaran las secciones que son de gran importancia:

El servicio SSH por default trabaja sobre el puerto 22 pero se puede cambiar:

Port 22 ## PUERTO POR DEFAULT

El parámetro ListenAddress especifica las direcciones de las interfaces de donde se van a recibir peticiones OJO con esta sección si vamos a accesar desde una red externa como la casa entonces dejarlo como esta sino pues hay que especificar la red:

ListenAddress 0.0.0.0 ## IP por Default para acceder desde cualquier red

Esta es la sección critica a mi manera de ver porque indicamos si el usuario ROOT puede acceder vía ssh yo en lo personal lo deshabilito y entro con un usuario del sistema diferente a root

PermitRootLogin no

También podemos especificar si se va a ejecutar aplicaciones graficas mediante SSH por ejemplo podemos usar VLC a través de SSH por si no son muy dados a usar comandos yo lo dejo como esta:

X11Forwarding no

Otra opción es permitir el acceso a ciertos usuarios de la siguiente manera:

AllowUsers tusuario, miotrousuario, uncolado

En fin son muchas las opciones que trae el archivo seria bueno que le echaran un vistazo y modifiquen lo que mejor crean ustedes que es para su servidor pero siempre pensando en la seguridad y los riesgos que conlleva hacer una mala configuración.

Por último reiniciamos el servicio:

# /etc/init.d/ssh restart

NOTA: Si están detrás de un firewall tienen que abrir el puerto que han especificado pero si están en DMZ pues les recomiendo que pongan reglas IPTABLE por seguridad.

Ahora a hacer un test desde un cliente usando el terminal:

# Ssh usuario@midominio

Cuando se logueen verán lo siguiente:

Cuando se loguea

También se pueden conectar desde un Windows utilizando la herramienta Putty

Loguearse usando Putty

Mas info sobre configuración: Aquí

Fuente: Aquí

Descargar el Putty: Aqui