Protegiendo las bases de datos contra accesos no autorizados

Una de las mayores preocupaciones de quienes guardan datos sensibles en bases de datos es acerca de la seguridad con que se cuenta para evitar el acceso no autorizado. Entonces ¿qué podemos decir sobre este tema?

Primero, y fundamental, que la seguridad implica tomar muchas medidas de precaución, no solamente una.

La seguridad de una Base de Datos no debe estar basada en nombres de usuarios y en contraseñas. Realmente en Firebird el intruso solamente debe conocer la contraseña del usuario SYSDBA y ya podrá hacer lo que se le antoje.

Creer que la contraseña lo es todo en cuanto a seguridad, es un gran error.

¿Por qué?

Porque el elemento más débil en la seguridad, no es la contraseña sino que es … el usuario humano.

Si el usuario permite que le vean el teclado mientras escribe la contraseña … murió la seguridad

Si el usuario escribe la contraseña en un papel que otros pueden ver … murió la seguridad

Si el usuario le dice a otra persona cual es su contraseña … murió la seguridad

Si el usuario elige una contraseña fácil de descubrir … murió la seguridad

Si el intruso puede copiar la Base de Datos en un pen-drive … murió la seguridad

Explicación:

Si alguien puede ver tu teclado mientras estás escribiendo la contraseña del usuario SYSDBA entonces te puede estar filmando (quizás a una distancia prudencial), con cualquier teléfono celular (móvil) o con esas minicámaras que se disimulan en bolígrafos, relojes, u otros aparatos. Luego, simplemente reproduce la filmación y podrá descubrir cuales teclas presionaste, y en que orden lo hiciste. Y listo, ya conoce la contraseña.

Si escribes la contraseña en un papel, archivo de texto, planilla Excel, o cualquier otro lugar donde alguien más puede leerlo, entonces ya la consiguió. Hay gente que se inventa una contraseña muy complicada, y para no olvidarla, la anota en un papel que deja en el primer cajón de su escritorio. Algo como: «contraseña de SYSDBA = euldlm67»

Mujeres sexies que actuaron de espías hay varias en la Historia, quizás la más conocida haya sido Mata Hari, quien se acostaba con los jefes del ejército enemigo para sacarles información. En una noche de juerga, sexo y borrachera, lo que menos le importará a un fulano es contarle cual es la contraseña del usuario SYSDBA a su amante. Estos casos, aunque no involucren sexo, se conocen como «Ingeniería Social» donde a la víctima se le quita información usando la psicología. Diciéndolo lo importante que es, o algunas otras frases se lo dispone a compartir esa contraseña que debería mantener en secreto.

Hay contraseñas que son muy fáciles de descubrir, entre ellas tenemos a: «123456», «1234567», «12345678», «admin», «supervisor», «root» y unas 50 más, que son ampliamente utilizadas por una gran cantidad de personas. Cualquier aprendiz de hacker sabe que debe empezar a intentar acceder con ellas, pues muchas personas las utilizan. Si se conocen algunos datos del usuario eso también puede facilitar la obtención de la contraseña. Por ejemplo, en las mujeres es muy frecuente que usen el nombre del novio, del perro, o del hijo. En los hombres, el club de fútbol, un jugador famoso, un personaje de historieta o de ficción. Entonces, usando «Ingeniería Social» se averiguan esos nombres y listo.

Cambiando la contraseña del usuario

Sabiendo que el eslabón más débil es el usuario porque muchos no entienden la importancia de mantener la contraseña en absoluto secreto, hay que tratar de disminuir la probabilidad de que si la comunican a otra persona, por accidente o por intención, el intruso pueda conectarse a la Base de Datos.

Un método, que no es infalible pero ayuda a aumentar la seguridad es el siguiente:

• En las aplicaciones (Contabilidad, Ventas, Producción, Sueldos, etc.) jamás se debe permitir que ingrese el usuario SYSDBA
• En las aplicaciones (Contabilidad, Ventas, Producción, Sueldos, etc.) jamás debe permitirse que ingrese un usuario con el rol RDB$ADMIN, pues en esa Base de Datos tendrá los mismos privilegios que el usuario SYSDBA
• La aplicación debe verificar que el usuario no sea SYSDBA y que el rol utilizado no sea RDB$ADMIN
• Las tareas administrativas de la Base de Datos que requieren del usuario SYSDBA o de un usuario con el rol RDB$ADMIN (backup, sweep, etc.) deben realizarse a través de una aplicación diseñada para ese efecto. Nada de hacerlas en la línea de comando.
• La contraseña que el usuario introduce en esa aplicación jamás debe ser la contraseña verdadera del usuario SYSDBA o del usuario que tiene el rol RDB$ADMIN. La aplicación debe transformar la contraseña introducida por el usuario en otra contraseña, en la verdadera contraseña. Esto es muy fácil de hacer, por ejemplo si se reemplaza cada carácter de la contraseña por el siguiente, se convertirá a «12345678» en «23456789». La contraseña que introduce el usuario es «12345678», la verdadera contraseña es «23456789». Si el idiota del usuario le comunica su contraseña a otra persona, y esta otra persona quiere conectarse desde la línea de comandos como SYSDBA con la contraseña «12345678» (que es la que el usuario conoce y utiliza) no lo conseguirá, porque esa no es la verdadera contraseña. Esa es la contraseña que introduce en la aplicación, pero no es la contraseña requerida para realizar la conexión. Desde luego que el algoritmo utilizado para cambiar la contraseña no debe ser tan simple como el de este ejemplo. Un buen algoritmo puede convertir a «12345678» en algo como «X&9_7sxÇ»

Protegiendo una Base de Datos:

En entornos donde la seguridad es importante, las medidas de protección mínimas son las siguientes:

1. La computadora donde se encuentra el Servidor no debe tener puertos USB habilitados ni grabador de CD/DVD
2. La computadora donde se encuentra el Servidor no debe tener acceso directo a Internet
3. La computadora donde se encuentra el Servidor debe encontrarse en una habitación aparte, la cual normalmente se encuentra cerrada con llave, y esa llave se guarda en un lugar seguro
4. La conexión a la Base de Datos se hace siempre con alias
5. Se registra en un archivo de log, que se guarda afuera de la Base de Datos, los datos de cada conexión: usuario, IP de su computadora, fecha de entrada, hora de entrada, fecha de salida, hora de salida
6. Se restringe el acceso a la Base de Datos fuera de los días y horarios establecidos
7. La contraseña que escribe el usuario en la aplicación, nunca debe ser la usada para la conexión sino que debe sometérsela a algún algoritmo que la convierta en la contraseña correcta. Un ejemplo muy sencillo: si en la aplicación el usuario escribe la contraseña «12345678» una función debe convertirla en «23456789», que es la contraseña reconocida por la Base de Datos. De esa manera, si alguien conoce la contraseña del usuario y quiere acceder a la Base de Datos desde afuera de la aplicación no lo conseguirá porque estará intentando la conexión con una contraseña que no es la correcta.

Conclusión:

Si queremos tener bases de datos seguras lo más importante es siempre concientizar a los usuarios sobre la gran importancia de mantener el acceso restringido y que nunca deben comunicar sus contraseñas a otras personas, por ningún motivo.

Pero tipos que no entenderán aunque se les repita mil veces siempre existirán, por lo tanto no debemos confiar en la gente sino que debemos preocuparnos nosotros mismos de ese aspecto.

La seguridad jamás debe estar basada solamente en contraseñas, porque no es el punto más débil. El punto más débil siempre son los usuarios descuidados, negligentes, ignorantes, o indolentes. Ante gente así, ni el mejor algoritmo de encriptación del mundo servirá de algo.

Un método para mejorar la seguridad que proporcionan las contraseñas es convertir la contraseña introducida por el usuario en otra contraseña, que es la correcta para realizar la conexión.

Artículos relacionados:

Una técnica para dificultar el acceso no autorizado

Inferencia de datos

Impidiendo la conexión a una Base de Datos

Atacando a una Base de Datos: SQL injection

Evitando que los mirones averigüen nuestro password en ISQL

El índice del blog Firebird21

El foro del blog Firebird21

¿Cuáles usuarios tienen el rol RDB$ADMIN?

Como seguramente sabes, si un usuario tiene el rol RDB$ADMIN en una Base de Datos entonces en esa Base de Datos puede hacer de todo, exactamente igual a que si fuera el usuario SYSDBA o el creador de la Base de Datos.

Por lo tanto, a veces puede ser importante responder a la pregunta: ¿Quiénes tienen el rol RDB$ADMIN en esta Base de Datos?

El siguiente SELECT te lo dirá:

SELECT
   *
FROM
   RDB$USER_PRIVILEGES
WHERE 
   RDB$RELATION_NAME = 'RDB$ADMIN';

Como puedes ver, esa información la extraemos de la tabla RDB$USER_PRIVILEGES pues es en esa tabla donde se guardan todos los privilegios (derechos, permisos) que tiene cada usuario. Obtendremos algo similar a esto:

Captura 1. Si haces clic en la imagen la verás más grande

Entonces, en esta Base de Datos, hay 3 usuarios que pueden conectarse con el rol RDB$ADMIN, ellos son: WOJEDAR, FATIMA y PRUEBA.

Artículos relacionados:

Derechos que poseen los usuarios de la Base de Datos

El índice del blog Firebird21

El foro del blog Firebird21

 

Algo más sobre GRANT y ROLE

Los conceptos sobre GRANT y sobre ROLE pueden ser un poco difíciles de entender para quienes nunca los habían usado, así que con este artículo trataré de aclarar algunos conceptos y dudas que se puedan tener:

1. Cuando un usuario consigue conectarse a la Base de Datos eso significa que tanto su nombre como su contraseña están reconocidos por el Firebird.
2. Sin embargo, el hecho de haberse conseguido conectar no implica que pueda ejecutar exitosamente algún comando. Si no tiene derechos (permisos, privilegios) en esa Base de Datos entonces todos sus intentos fallarán. Ni siquiera podrá hacer un SELECT.
3. Para que el usuario pueda ejecutar exitosamente algún comando, alguien previamente tuvo que haberle otorgado ese derecho (permiso, privilegio).
4. Ese «alguien» que le otorgó el derecho puede ser el usuario SYSDBA, el creador de la Base de Datos, o un usuario que tiene el rol RDB$ADMIN con la opción de otorgar derechos, nadie más.
5. Un rol es un grupo de usuarios. Los derechos (permisos, privilegios) que se otorgan a un rol automáticamente se otorgan a todos los usuarios que se conectan usando ese rol
6. Para que un usuario pertenezca a un rol otro usuario debió haberlo hecho miembro de ese rol. Ese «otro usuario» puede ser SYSDBA, el creador de la Base de Datos o un usuario que tiene el rol RDB$ADMIN con la opción de otorgar derechos, nadie más.
7. Cuando un usuario se conecta a la Base de Datos puede hacerlo especificando un rol o sin especificar un rol.
8. Si se conecta sin especificar un rol, entonces tendrá solamente los derechos que a él específicamente se le hayan otorgado
9. Si se conecta especificando un rol entonces tendrá todos los derechos que se le otorgaron específicamente a él más todos los derechos que tiene ese rol
10. Un usuario puede pertenecer a muchísimos roles pero cuando se conecta solamente puede elegir uno de ellos y solamente tendrá los derechos que le corresponden a ese rol.

Ejemplo:

Al usuario JUAN se le otorgó el derecho de hacer SELECT a la tabla CLIENTES.

Al rol R_CONTABILIDAD se le otorgó el derecho de hacer SELECT a la tabla VENTAS.

Al usuario JUAN se lo hizo miembro del rol R_CONTABILIDAD.

Si el usuario JUAN se conecta sin especificar un rol, entonces podrá hacer SELECT a la tabla CLIENTES pero no a la tabla VENTAS.

Si el usuario JUAN se conecta especificando el rol R_CONTABILIDAD entonces podrá hacer SELECT a la tabla CLIENTES y también a la tabla VENTAS.

El usuario JUAN no podrá hacer SELECT a la tabla COMPRAS porque ni a él ni al rol R_CONTABILIDAD se le otorgó el derecho de hacerle un SELECT a esa tabla. Si más adelante a él o al rol R_CONTABILIDAD se le otorga el derecho de SELECT a la tabla COMPRAS entonces cuando vuelva a conectarse podrá hacer el SELECT, pero mientras tanto le será imposible.

Recuerda:

Un rol es un grupo de usuarios, si varios usuarios necesitan tener los mismos derechos entonces ahorrarás mucho tiempo creando un rol con esos derechos y luego otorgándole ese rol a cada usuario. Si no creas un rol entonces podrías olvidarte de asignarle un derecho a un usuario y además escribirás mucho más y en consecuencia perderás mucho tiempo.

Muy importante:

En general, por motivos de seguridad, lo recomendable es que no se otorguen derechos específicos a los usuarios sino a los roles. De esta manera si un usuario se conecta sin especificar un rol nada podrá hacer en la Base de Datos, ni siquiera un SELECT. Por lo tanto, siempre deberá conectarse usando un rol y en ese caso solamente tendrá los derechos (permisos, privilegios) que se le hayan otorgado al rol con el cual se conectó.

Artículos relacionados:

Entendiendo los derechos de acceso

Otorgando permisos con EMS SQL Manager

Delegando el otorgamiento de derechos

Un stored procedure para otorgarle TODOS los derechos a un usuario

El índice del blog Firebird21

 

Atacando a una Base de Datos: SQL injection

Las bases de datos siempre se encuentran expuestas a ser atacadas por personas mal intencionadas. Eso le puede ocurrir tanto a una Base de Datos que se encuentra en una red local como a una Base de Datos que se encuentra en una red remota, como Internet, por ejemplo. En este último caso el peligro es mucho mayor porque el atacante puede estar en la otra mitad del mundo y aunque lo descubramos no se podrá tomar medidas punitivas contra él. En cambio, si el atacante es un empleado de nuestra propia empresa siempre de alguna forma se le podrá castigar.

Nuestra tarea, por supuesto, es evitar que los ataques tengan éxito. Para ello debemos proteger a la Base de Datos lo más que podamos. A veces nuestros esfuerzos serán insuficientes pero en general los atacantes desistirán de continuar con sus ataques si se dan cuenta que se enfrentan a una Base de Datos que está muy protegida.

Una forma común de atacarla es a través de un método llamado en inglés «SQL injection».

¿Qué significa «SQL injection»?

Que al comando SQL se le está agregando algo, se le está inyectando algo. Un código que no debería estar. Ese código adicional que agregó el atacante es el que nos causará problemas.

Ejemplo 1. Un ataque trivial de SQL injection

Supongamos que tenemos un sitio web para vender productos en línea. Los visitantes de nuestro sitio web pueden escribir el código del producto que les interesa conocer características y precios.

Todo bien hasta ahí, ¿verdad?

Quizás no, si no tomamos las debidas precauciones puede ser muy vulnerable.

En nuestra página web tenemos un campo de texto donde el visitante escribirá el código del producto que le interesa y un botón «submit» que usará para enviar su solicitud. En nuestro programa escribimos algo así:

lcComando = '''SELECT * FROM PRODUCTOS WHERE PRD_CODIGO = ' || lcCodigo || ';'''

Un vistitante normal podría querer conocer las características y precios del producto que tiene código 127 y entonces nuestro comando quedaría como:

lcComando = 'SELECT * FROM PRODUCTOS WHERE PRD_CODIGO = 127';

Y estaría perfecto, en condiciones normales no tendríamos problemas. Pero un visitante malintencionado podría escribir algo como:

127 or 1=1

 con lo cual, nuestro comando quedaría como:

lcComando = 'SELECT * FROM PRODUCTOS WHERE PRD_CODIGO = 127 or 1=1';

¡¡¡CUIDADO!!! esa condición SIEMPRE será verdadera porque SIEMPRE tendremos que 1 es igual a 1.

En este caso el atacante podrá ver las características y precios no solamente del producto cuyo código es 127 sino de TODOS los productos que tenemos en nuestra Base de Datos.

¿No importa que los vea, están para ser vistos?

Quizás en el caso de los productos no importe, pero en otros casos sí podría importar.

Ejemplo 2. Un ataque peligroso de SQL injection

El Ejemplo 1. mostró el concepto pero no era peligroso porque el atacante solamente vio datos, no modificó ni borró algo, entonces en muchos casos sería algo trivial y no muy preocupante. Pero el atacante sí puede borrar algo, si escribe:

127;DELETE FROM PRODUCTOS

porque en ese caso nuestro comando quedaría así:

lcComando = 'SELECT * FROM PRODUCTOS WHERE PRD_CODIGO = 127;DELETE FROM PRODUCTOS';

 ¿Y qué hará el Firebird en ese caso?

Pues ignorará al primer comando (o sea, el SELECT) y ejecutará el segundo comando (o sea el DELETE).

Y ahora, lo que hizo el atacante es MUY PELIGROSO porque borró todas las filas de nuestra tabla llamada PRODUCTOS.

Detectando si el ataque tuvo éxito

¿Y cómo puede saber el atacante si su ataque tuvo éxito?

Pues simplemente escribiendo el código de un producto que debía existir, por ejemplo el 127, con lo cual nuestro comando quedaría así:

lcComando = 'SELECT * FROM PRODUCTOS WHERE PRD_CODIGO = 127';

Si el atacante escribió 127 antes de lanzar el ataque y recibió datos, y luego de lanzar el ataque vuelve a escribir 127 y no recibe datos entonces puede estar 100% seguro de que su ataque tuvo éxito.

Claro, para eso tendría que saber que la tabla se llama PRODUCTOS, si la tabla tiene otro nombre evidentemente su ataque no funcionó. ¿Y qué puede hacer en ese caso? Pues probar con otros nombres similares, tales como: PROD, PRODS, PRODUCTO, PRODUCTS, ARTICULOS, ARTICLES, ARTICS, ARTS, etc.

Si alguna vez al enviar el código 127 no recibe datos entonces sabrá (al menos) cuatro cosas:

1. El nombre de la tabla
2. Que su ataque tuvo éxito
3. Que el diseñador del sitio web no se preocupó por la seguridad
4. Que puede continuar atacando a esa Base de Datos porque no está protegida

Ahora que ya borró todas las filas de la tabla PRODUCTOS puede continuar escribiendo otros comandos similares, tales como:

DELETE FROM CLIENTES
DELETE FROM PROVEEDORES
DELETE FROM USERS
DELETE FROM USUARIOS
DELETE FROM VENTAS
DROP CLIENTES
DROP PROVEEDORES
DROP VENTAS
etc.

En estos casos, no podrá saber si su ataque tuvo éxito o no, pero si escribe muchísimos comandos DELETE es muy probable que algunos de ellos sí borren todas las filas de algunas tablas.

¿Cómo evitamos los ataques de SQL injection?

Ya sabemos como la Base de Datos puede ser atacada, ¿cómo la defendemos?

1. Validando que el visitante no introduzca espacios en blanco
2. Validando que el visitante no introduzca puntos y comas
3. Validando que el visitante solamente introduzca dígitos (0 .. 9)
4. Validando que el visitante no introduzca la palabra DELETE
5. Validando que el visitante no introduzca la palabra MODIFY
6. Validando que el visitante no introduzca la palabra DROP
7. Validando que la longitud de nuestra variable (llamada lcComando en estos ejemplos) no sea mayor que la predeterminada. Si nuestros códigos tienen un máximo de 4 dígitos entonces la longitud de lcComando nunca debería ser mayor que 47 (en nuestros ejemplos, claro).

Entonces, en nuestro stored procedure (o en el código fuente de nuestro lenguaje de programación) deberíamos escribir algo como:

IF (POSITION('DROP' IN lcComando) > 0) THEN BEGIN
-- ERROR, no se debe ejecutar el comando, la Base de Datos fue atacada.
END

Conclusión:

Todas las bases de datos pueden ser atacadas y como puedes ver es demasiado fácil hacerlo, ni siquiera se necesita de un programa que ayude. Aquí hemos visto algunos de los muchos métodos que pueden usar los atacantes. Mi objetivo no es enseñarte a atacar bases de datos sino mostrarte que son muy vulnerables y que si no las proteges entonces pueden ser facilmente destruidas.

Nunca debes confiar en que tu Base de Datos no será atacada porque no tiene algo interesante o de valor, muchos las atacan por diversión, porque lo toman como un juego, para pasar un buen rato, desafiando a sus amigos quienes realizan más ataques, cosas así. A muchos ni les interesa el contenido, solamente les resulta divertido hacerlo. Pero para tí puede ser un perjuicio enorme. Así que, mucho cuidado.

Artículo relacionado:

El índice del blog Firebird21

 

Impidiendo la conexión a una Base de Datos

En ocasiones queremos evitar que un usuario, un proceso o una computadora se conecten a nuestra Base de Datos. O varios usuarios, varios procesos o varias computadoras.

Ya habíamos visto algunos artículos sobre este tema:

Como evitar que se conecten a una Base de Datos

Evitando que un usuario se conecte más de una vez a la Base de Datos

Evitando que un usuario se conecte más de una vez (método mejorado)

En el presente artículo nos explayaremos más sobre como evitar las conexiones indeseadas.

A partir del Firebird 2.1 podemos usar los llamados triggers de las bases de datos (database triggers, en inglés) y nos servirán perfectamente para lo que pretendemos lograr.

El primer paso es crear una excepción, la cual mostrará un mensaje al usuario. En realidad esto no es obligatorio, podríamos dejar que el Firebird muestre su mensaje por defecto pero ese mensaje estará en inglés. Si queremos personalizar el mensaje entonces deberemos crear una excepción, como la siguiente:

CREATE EXCEPTION
   E_ACCESO_NO_PERMITIDO 'No tienes permiso para conectarte a esta Base de Datos' ;

A continuación crearemos los triggers de bases de datos que necesitaremos:

Un trigger para evitar que los usuarios se conecten a la Base de Datos:

Listado 1.

CREATE TRIGGER NEW_DBTRIGGER_C
   ACTIVE ON CONNECT
   POSITION 2
AS
BEGIN

   IF (CURRENT_USER IN ('JUAN', 'MARIA', 'ESTELA','MONICA')) THEN
      EXCEPTION E_ACCESO_NO_PERMITIDO;

END;

Ningún usuario cuyo nombre esté dentro del IN (en este caso: JUAN, MARIA, ESTELA y MONICA) podrá conectarse a la Base de Datos.

Un trigger para evitar que los programas se conecten a la Base de Datos:

Listado 2.

CREATE TRIGGER NEW_DBTRIGGER_C1
   ACTIVE ON CONNECT
   POSITION 3
AS
BEGIN

   IF (EXISTS(SELECT
                 *
              FROM
                 MON$ATTACHMENTS M
              WHERE
                 M.MON$ATTACHMENT_ID = CURRENT_CONNECTION AND
                (NOT M.MON$REMOTE_PROCESS IN ('MI_PROG1.EXE', 'MI_PROG2.EXE')))) THEN
      EXCEPTION E_ACCESO_NO_PERMITIDO;

END;

En este caso solamente permitiremos el acceso a los programas cuyos nombres se encuentren en el IN, o sea: MI_PROG1.EXE y MI_PROG2.EXE. Evidentemente que tú escribirías allí los nombres de tus propios programas.

¿Cuál es el defecto que tiene esta protección? Que si el intruso sabe que MI_PROG1.EXE puede conectarse entonces podría renombrar a su propio programa como MI_PROG1.EXE y así conseguirá la conexión. Por eso siempre es importante que los mensajes de las excepciones le den al intruso muy poca información. Sería muy mala idea que el mensaje sea algo como: «Solamente se pueden conectar MI_PROG1.EXE y MI_PROG2.EXE» porque en ese caso lo primero que se le ocurrirá al intruso será renombrar a su programa y conseguirá conectarse. Además, hay que tomar en cuenta otro aspecto: no se debe impedir el acceso a los programas legítimos que podamos necesitar, como: GBAK.EXE

Un trigger para evitar que desde una computadora se conecten a la Base de Datos:

Listado 3.

CREATE TRIGGER NEW_DBTRIGGER_C2
   ACTIVE ON CONNECT
   POSITION 4
AS
BEGIN

   IF (EXISTS(SELECT
                 1
              FROM
                 MON$ATTACHMENTS M
              WHERE
                 M.MON$ATTACHMENT_ID = CURRENT_CONNECTION AND
                 M.MON$REMOTE_ADDRESS IN ('192.168.0.100', '192.168.0.104'))) THEN
      EXCEPTION E_ACCESO_NO_PERMITIDO;

END;

En este caso, las computadoras cuyos IP son 192.168.0.100 ó 192.168.0.104 jamás podrán conectarse a nuestra Base de Datos, siempre se les rechazarán todos los intentos de conexión.

Un trigger para evitar que desde una subred se conecten a la Base de Datos:

Listado 4.

A veces queremos que se rechace la conexión desde toda una subred y escribir todos los IP después del IN como se mostró en el ejemplo anterior sería muy largo y muy tedioso. Para esos casos tenemos una mucha mejor alternativa:

CREATE TRIGGER NEW_DBTRIGGER_C3
   ACTIVE ON CONNECT
   POSITION 4
AS
BEGIN

   IF (EXISTS(SELECT
                 1
              FROM
                 MON$ATTACHMENTS M
              WHERE
                 M.MON$ATTACHMENT_ID = CURRENT_CONNECTION AND
                 M.MON$REMOTE_ADDRESS STARTING WITH '192.168.14')) THEN
      EXCEPTION E_ACCESO_NO_PERMITIDO;

END;

Aquí estamos rechazando las conexiones de todas las computadoras de la subred 192.168.14, o en otras palabras cualquier computadora cuyo IP empiece con esos números será rechazada. Esto puede ser muy útil cuando por ejemplo tenemos una Base de Datos para los sueldos y jornales de los empleados y no queremos que desde otras computadoras de la Empresa puedan curiosear en ella. Entonces, de un plumazo las rechazamos a todas las que no se encuentran en nuestra misma subred.

Un trigger para evitar que se conecten fuera del horario autorizado:

Si el horario laboral de la empresa va de 8:00 a 18:00 entonces sería muy sospechoso que alguien tratara de conectarse a las 23:45 ¿verdad? ¿Por qué alguien querría conectarse a esa hora? Para estos casos podríamos tener un trigger que restrigiera el acceso fuera del horario establecido.

Listado 5.

CREATE TRIGGER NEW_DBTRIGGER_C4
   ACTIVE ON CONNECT
   POSITION 5
AS
BEGIN

 IF (CURRENT_USER <> 'SYSDBA' AND
     CURRENT_TIME < '07:45:00' OR CURRENT_TIME > '18:15:00') THEN
    EXCEPTION E_ACCESO_NO_PERMITIDO;

END;

Aquí, solamente al usuario SYSDBA le permitimos conectarse a cualquier hora que desee, todos los demás usuarios deberán iniciar la conexión entre las 07:45:00 y las 18:15:00

Desde luego que también podríamos restringir la conexión por los días de la semana: de Lunes a Viernes tendrían un horario de conexión, los Sábados tendrían otro horario de conexión y los Domingos tendrían otro horario.

O podríamos realizar combinaciones: MARCELA tiene un horario, SILVIA tiene otro horario, SUSANA tiene otro horario, etc.

Conclusión:

Para mantener la confidencialidad y la seguridad de los datos y de la información muchas veces es muy importante impedir que personas no autorizadas puedan conectarse a la Base de Datos. Esas personas podrían tener derechos de conexión a otras bases de datos de la Empresa, pero no a esta Base de Datos.

Usando los triggers de las bases de datos podemos impedir (o al menos dificultar) que se conecten quienes no deberían conectarse. Pero recuerda que ningún método es infalible. El usuario SYSDBA y el creador de la Base de Datos siempre podrán conectarse. Y podrían irse a almorzar dejando la conexión abierta y el intruso aprovechar la ocasión.

Hay muchísimas combinaciones más que puedes realizar pero con los ejemplos anteriores ya tendrás una buena idea de lo que se puede lograr.

Artículos relacionados:

Como evitar que se conecten a una Base de Datos

Evitando que un usuario se conecte más de una vez a la Base de Datos

Evitando que un usuario se conecte más de una vez (método mejorado)

El índice del blog Firebird21

El foro del blog Firebird21

Inferencia de datos

Como sabes, las bases de datos son muy útiles para guardar y procesar datos pero también pueden conllevar un compromiso con la seguridad de los mismos. Muchas veces lo que se guarda en sus tablas es para que lo vean solamente algunos usuarios, no todos los usuarios.

Esto es más importante en las aplicaciones que se diseñan para los organismos de seguridad (militares, policías, servicios de inteligencia, etc.) pero también puede ocurrir con empresas comerciales.

¿Qué significa inferir?

Según el Diccionario es obtener una conclusión, deducir algo a partir de los datos con los que se cuenta.

Ejemplo

Tenemos una tabla llamada SALARIOS donde se guarda el salario de cada empleado de la Empresa. El personal de Recursos Humanos es el encargado de elaborar los cheques de pago a esos empleados, pero no deben conocer el salario de los empleados de nivel superior, solamente deben conocer el salario de los empleados de nivel medio y nivel bajo.

Captura 1. Si haces clic en la imagen la verás más grande

En la Captura 1 estamos viendo el Identificador del Empleado, el Número del Mes, el Número del Año y el Monto de su salario. El Gerente de Recursos Humanos es «Juan» y él sí puede ver esa tabla. Pero su empleada «María» no debería ver el salario del empleado cuyo Identificador es 3, o sea que «María» debería ver esto:

Captura 2. Si haces clic en la imagen la verás más grande

Al mirar esa tabla ella nota que está faltando un empleado con Identificador igual a 3, y entonces cuando la Empresa contrata a un nuevo empleado cuyo nombre es «Martín» ella trata de usar el Identificador 3 para asignárselo a «Martín» y así no tener números de Identificación faltantes. Pero como el Identificador 3 sí existe (aunque ella no puede verlo) al intentar grabar los datos de «Martín» obtendrá un mensaje de error. Y como «María» es inteligente entonces infiere (es decir: deduce) que sí existe un empleado con Identificador igual a 3 pero que a ella no le permiten verlo.

Y como además de inteligente es curiosa a partir de ese momento se dedica a intentar averiguar los datos del empleado con Identificador 3, mediante tablas cruzadas, o algunas otras técnicas.

Diseñando para evitar inferencias

Si algún usuario puede inferir (deducir) que algo se le está ocultando entonces puede también inferir (deducir) que se trata de algo valioso, algo de lo cual podrá obtener provecho económico o de otro tipo. Por algo se le ocultan los datos ¿verdad?.

Entonces, cuando diseñamos nuestras bases de datos debemos pensar en como evitar las inferencias. No es fácil ante usuarios inteligentes y con muchos conocimientos de Informática pero debemos intentarlo.

La primera y elemental medida es impedir que los usuarios puedan asignar identificadores o códigos. Estos deberían ser elegidos y puestos automáticamente por el Servidor del Firebird o por nuestra aplicación.

Lo segundo a recordar siempre es que los identificadores son para uso interno y los códigos son para uso externo. Eso implica que los usuarios jamás deberían ver los identificadores (ni siquiera necesitan saber que existen) y manejarse siempre exclusivamente con códigos. En general los códigos no deberían cambiarse pero si se cambian no afectarán a la operatividad de la Base de Datos porque ésta no los utiliza para nada, son solamente para mostrárselos a los usuarios.

Tercero, los códigos no deberían ser de la forma «A, B, C, D, E, …» o de la forma «1, 2, 3, 4, 5, …» porque si falta una letra o un número en la secuencia entonces es muy fácil inferir que algo se está ocultando.

Conclusión:

Cuando se diseña una Base de Datos un aspecto importante es el relacionado con la seguridad de los datos. Y dentro de la seguridad hay que tomar en cuenta que los usuarios no autorizados a ver una información no puedan realizar inferencias para saber que esa información existe.

En el caso de nuestro ejemplo «María» rápidamente descubrió que se le estaban ocultando los salarios del empleado cuyo Identificador es 3. ¿Por qué? porque la Base de Datos estaba mal diseñada y se le permitía a ella asignar un Identificador al nuevo empleado. En una Base de Datos bien diseñada ningún usuario, por ningún motivo, puede asignar o cambiar un Identificador o un Código. Si alguna vez se requiere hacer eso entonces debería hacerse exclusivamente usando nuestra aplicación.

Artículos relacionados

Usando IDENTIFICADORES y CÓDIGOS en nuestras tablas

El índice del blog Firebird21

Ejemplos del uso de Zebedee con Firebird

Aquí hay algunos ejemplos del uso de Zebedee con Firebird.

En estos dos artículos, habíamos visto para que sirve Zebedee y como usarlo. Ahora, para aclarar mejor el tema, algunos ejemplos:

Usando Zebedee con Firebird

Usando Zebedee con Firebird. Parte 2

Servidor

Línea de comandos

START ZEBEDEE -s localhost:3050

Usando un archivo de configuración

START ZEBEDEE -f SERVIDOR1.ZBD

Cliente

Línea de comandos

START ZEBEDEE 3051:99.999.999.99:3050

Usando un archivo de configuración

START ZEBEDEE -f CLIENTE.ZBD

Conexión con una Base de Datos Firebird

CONNECT localhost/3051:E:\BASESDATOS\MiBase.FDB USER SYSDBA PASSWORD masterkey;

NOTAS:

1. En la computadora donde se encuentra el Servidor de Zebedee debe estar abierto el puerto 11965
2. Las demás computadoras no necesitan (y no deberían) tener puertos abiertos
3. Cualquier usuario puede conectarse, no solamente SYSDBA, por supuesto que con sus nombres y passwords correctos
4. No es obligatorio escribir el comando START, pero si no se lo escribe entonces la ventana «Símbolo del sistema» se queda congelada. Zebedee funciona igual, pero esas ventanas congeladas no les gustan a los usuarios
5. Las computadoras Cliente deben poder acceder a la computadora Servidor. Eso significa que la IP del Servidor debe ser pública, de una VPN como Hamachi o encontrarse en una red local
6. No suele justificarse usar Zebedee en una red local, porque el tiempo que se gana al enviar los datos comprimidos se pierde al comprimir y descomprimir esos datos. Se justificaría su uso si aún tratándose de una red local hay computadoras que no son confiables
7. Si se usa un archivo de configuración, ese archivo no debe encontrarse en una carpeta compartida o cualquiera podría modificarlo a su antojo
8. Si la conexión con el Servidor de Firebird se realiza a través de Internet entonces usar Zebedee (o algún programa similar) es un requisito ineludible

Artículos relacionados:

Proteger a las bases de datos visibles en Internet

Usando Zebedee con Firebird

Usando Zebedee con Firebird. Parte 2

El índice del blog Firebird21

Usando Zebedee con Firebird. Parte 2

Zebedee es un programa que nos permite enviar datos de una computadora a otra computadora de forma fácil, rápida y segura. Su principal utilidad es cuando la conexión entre ambas computadoras se hace vía Internet; puede usarse también en una red local pero usarlo en una red local se justifica muy poco.

No necesariamente debe usarse con Firebird, puede usarse siempre que se requiera enviar de forma fácil, rápida y segura datos entre dos computadoras conectadas por Internet pero en el blog solamente mostraremos su uso con Firebird, para los demás casos puedes leer su documentación.

En este artículo habíamos visto lo necesario para hacerlo funcionar correctamente:

https://firebird21.wordpress.com/2013/09/12/usando-zebedee-con-firebird/

y ahora veremos las demás opciones que pueden interesarnos cuando lo usamos con Firebird. En la Captura 1 vemos todas las opciones posibles:

Captura 1. Si haces clic en la imagen la verás más grande

pero como dijimos anteriormente, solamente algunas de ellas utilizaremos con Firebird.

Instalarlo como Servicio del Windows

Los Servicios del Windows son programas que están siempre ejecutándose: al encender la computadora empiezan a ejecutarse y continúan hasta el momento en que se apaga la computadora. Instalarías a Zebedee como un Servicio si constantemente se están conectando a una Base de Datos mediante Internet; si es algo esporádico entonces no necesitas instalarlo como un Servicio, simplemente lo ejecutas cada vez que lo requieres y ya.

Para que Zebedee se instale como un Servicio:

1. Debes abrir la ventana «Símbolo del sistema» como Administrador
2. Debes escribir: Zebedee -S install

Captura 2. Si haces clic en la imagen la verás más grande

Usando archivos de configuración

Además de escribir las opciones de Zebedee en la línea de comandos también tienes la posibilidad de escribirlas en un archivo de configuración, de esa manera te resultará más fácil personalizarlo. Hay dos archivos de configuración:

• El que usará el Servidor de Zebedee
• El que usará el Cliente de Zebedee

En ambos casos los nombres pueden ser cualesquiera pero la extensión debe ser .ZBD si queremos que al hacer doble clic sobre ellos sean utilizados por Zebedee.

Para especificar un archivo de configuración debemos escribir su nombre a continuación de la opción -f

Para impedir que el Zebedee parezca haberse quedado «colgado» debes ejecutarlo con el comando START

Captura 3. Si haces clic en la imagen la verás más grande

 Todas las líneas son de la forma:

PalabraClave Valor     # Todo lo que viene después del símbolo de numeral es un comentario

Donde PalabraClave es una palabra y Valor es un número, un valor boolean o un string. Si es un string debe estar rodeado por comillas o por apóstrofos. Si es boolean debe ser true o false. Todo lo que escribas a continuación del símbolo # será tratado como un comentario.

Caso 1. El Servidor de Zebedee y el Servidor de Firebird en la MISMA computadora

Si ambos Servidores se encuentran en la misma computadora entonces puedes usar este archivo de configuración, guárdalo por ejemplo con el nombre SERVIDOR1.ZBD:

# Usar este archivo de configuración cuando el Servidor de Zebedee y el Servidor de Firebird están en la MISMA computadora

VERBOSITY 2    # Muestra mensajes detallados

SERVER TRUE    # Se está configurando al Servidor de Zebedee

DETACHED TRUE  # Zebedee se ejecuta en el background. Para que no parezca haberse "colgado" se debe escribir: START ZEBEDEE -f SERVIDOR1.ZBD

UDPMODE FALSE  # No se necesita UDP con Firebird

LOGFILE "./SERVIDOR1.LOG" # Envía los mensajes de LOG a este archivo

REDIRECT NONE  # Cierra todos los puertos de redirección

REDIRECT 3050  # Redirige al puerto 3050, usado por el Servidor de Firebird

TARGETHOST localhost # El Servidor de Firebird está en esta misma computadora

COMPRESSION zlib:9 # Máximo nivel de compresión

KEYLENGTH 256 # Claves de 256 bits, son muy seguras

KEYLIFETIME 36000 # Las claves duran 36.000 segundos (10 horas)

MAXBUFSIZE 16383 # Tamaño máximo del buffer

Caso 2. El Servidor de Zebedee y el Servidor de Firebird en DISTINTAS computadoras

Si ambos Servidores se encuentran en computadoras distintas entonces puedes usar este archivo de configuración, guárdalo por ejemplo con el nombre SERVIDOR2.ZBD:

# Usar este archivo de configuración cuando el Servidor de Zebedee y el Servidor de Firebird están en DISTINTAS computadoras

VERBOSITY 2 # Muestra mensajes detallados

SERVER TRUE # Se está configurando al Servidor de Zebedee

DETACHED TRUE # Zebedee se ejecuta en el background. Para que no parezca haberse "colgado" se debe escribir: START ZEBEDEE -f SERVIDOR2.ZBD

UDPMODE FALSE # No se necesita UDP con Firebird

LOGFILE "./SERVIDOR2.LOG" # Envía los mensajes de LOG a este archivo

REDIRECT NONE # Cierra todos los puertos de redirección

REDIRECT 3050:IP_del_Servidor_Firebird:3050 # Redirige al puerto 3050, usado por el Servidor de Firebird

TARGETHOST IP_del_Servidor_Firebird # El Servidor de Firebird está en OTRA computadora

COMPRESSION zlib:9 # Máximo nivel de compresión

KEYLENGTH 256 # Claves de 256 bits, son muy seguras

KEYLIFETIME 36000 # Las claves duran 36.000 segundos (10 horas)

MAXBUFSIZE 16383 # Tamaño máximo del buffer

Configurando al Cliente

Puedes usar este archivo para configurar al Cliente, guárdalo por ejemplo con el nombre CLIENTE.ZBD:

# Este archivo de configuración debe encontrarse en cada computadora Cliente del Zebedee

VERBOSITY 1 # Mensajes básicos solamente

SERVER FALSE # No es un Servidor de Zebedee (por lo tanto es un Cliente)

DETACHED TRUE # Cierra la ventana "Símbolo del sistema"

TUNNEL 3051:99.999.999.99:3050 # Puedes elegir otro puerto local, no necesariamente debe ser 3051
 # Debes reemplazar 99.999.999.99 por el IP del Servidor de Firebird
 # Debes reemplazar 3050 por el puerto que usa el Servidor de Firebird
# Para conectarte a una Base de Datos:
# ------------------------------------
#
# CONNECT localhost/3051:IP_Servidor_Firebird:Ruta_a_la_Base_deDatos
#
# CONNECT localhost/3051:192.168.0.1:E:\basesdatos\Mibase.fdb USER SYSDBA PASSWORD masterkey;

Artículos relacionados

Usando Zebedee con Firebird

El índice del blog Firebird21

Usando Zebedee con Firebird

Como hemos visto en este artículo:

Proteger a las Bases de Datos visibles en Internet

Internet es muy inseguro y siempre existe la posibilidad de que algún hacker esté metiendo sus narices donde no debe y es nuestra responsabilidad evitar que curiosee en la Base de Datos o peor aún, que la corrompa.

Si un hacker irrumpió en la Base de Datos la culpa es toda tuya por no haberla protegido debidamente.

Un programa que nos puede ayudar con la tarea de protección es Zebedee.

¿Qué hace Zebedee?

• Crea un túnel entre dos computadoras
• Envía y recibe datos comprimidos y encriptados a través de ese túnel

Al comprimir los datos, el tamaño de éstos disminuye, al encriptarlos evita (o disminuye muchísimo) la posibilidad de que alguien pueda ver lo que se está enviando.

Por lo tanto se consiguen dos cosas:

1. que los datos viajen más seguros
2. que la transferencia se realice más rápido.

¿Cómo funciona Zebedee?

En forma muy similar a como funciona Firebird, o sea a través de un Servidor y de uno o varios Clientes.

• En una computadora se instala el Servidor del Zebedee. Su tarea es «escuchar» las conexiones de los Clientes. En otras palabras, está atento para responder las peticiones de los Clientes. Cuando un Cliente le hace una petición el Servidor comprime y encripta los datos pedidos y luego se los envía al Cliente
• En las demás computadoras se instala el Cliente del Zebedee. Su tarea es pedirle al Servidor del Zebedee que le envíe datos. Cuando recibe esos datos los descomprime, los desencripta, y los envía  a quien se los había pedido (el Cliente de Firebird).

El Cliente de Firebird —> a través del Cliente de Zebedee —> a través del Servidor de Zebedee —> le solicita algo al Servidor de Firebird

El Servidor de Firebird —> a través del Servidor de Zebedee —> a través del Cliente de Zebedee —> le responde al Cliente de Firebird

¿Dónde se instala el Servidor de Zebedee?

En cualquier computadora, no necesariamente en la misma donde está instalado el Servidor del Firebird

¿Dónde se instala el Cliente del Zebedee?

En cualquier computadora, no necesariamente en una que tenga instalado un Cliente del Firebird

¿Cómo se realiza la conexión?

A través de un puerto, el cual normalmente es el 11.965 y es el único puerto que debería estar libre para conectarse a Internet. Todos los demás puertos, incluyendo lógicamente el 3.050 (o el que use el Servidor del Firebird), deben estar bloqueados.

¿Cómo se abre un puerto?

El firewall del Windows (o cualquier otro firewall que estés usando) normalmente tiene bloqueados a los puertos. Desde luego que es obligatorio que uses un firewall, esa es una elemental medida de seguridad en cualquier computadora que esté conectada a Internet.

Para abrir el puerto 11.965 con el firewall de Windows:

Inicio | Panel de Control | Firewall de Windows | Configuración avanzada | Reglas de entrada | Nueva regla… | Puerto | TCP | Puertos locales específicos | 11965 | Permitir la conexión | (Dominio, Privado, Público) | Zebedee11965

Captura 1. Si haces clic en la imagen la verás más grande

Captura 2. Si haces clic en la imagen la verás más grande

Captura 3. Si haces clic en la imagen la verás más grande

Conexión no segura

En el Gráfico 1 puedes ver lo que sucede si el Servidor del Firebird está conectado a Internet sin usar a Zebedee (o algún programa similar)

Gráfico 1. Si haces clic en la imagen la verás más grande

Conexiones seguras

En el Gráfico 2 puedes ver algunas de las configuraciones de protección posibles:

Gráfico 2. Si haces clic en la imagen la verás más grande

El problema con la Opción 1 es que ambos Servidores están en la misma computadora. Y para que Firebird (o cualquier otro SGBDR) funcione al 100% lo recomendable es que se encuentre en una computadora dedicada, en una computadora donde está el Servidor del Firebird y ningún otro programa de uso autónomo, ni siquiera antivirus. Desde luego que la Opción 1 funcionará bien, pero de ser posible deberías elegir la Opción 3. Si usas la Opción 1 una medida elemental de precaución es que bloquees con tu firewall el puerto 3.050 (o el que sea que esté usando el Firebird) para evitar conexiones directas. Si no bloqueas el puerto 3.050 es como si no hubieras instalado el Zebedee, al menos en cuanto a seguridad se refiere.

La Opción 2 es la única que se puede usar si el usuario se conecta a través de su notebook (también llamada laptop) por ejemplo mientras está viajando.

La Opción 3 es posible (y preferible) dentro de la red local de la empresa. Se usa una computadora para tener en ella el Servidor del Firebird, cualquier otra computadora para el Servidor del Zebedee, cualquier otra computadora para el Cliente del Zebedee y todos los Clientes del Firebird se conectan al Servidor del Firebird a través primero del Cliente de Zebedee y luego del Servidor de Zebedee. La gran ventaja de la Opción 3 es que el Cliente del Zebedee se instala en una sola computadora y entonces no será necesario que cada vez que la empresa adquiera una nueva computadora se tenga que instalar en ella el Cliente del Zebedee. Las empresas medianas y grandes constantemente están aquiriendo nuevas computadoras y si se debe instalar en cada nueva computadora adquirida el Cliente del Zebedee eso causará un trastorno innecesario ya que puede ser evitado.

¿De dónde se puede descargar Zebedee?

http://www.winton.org.uk/zebedee/download.html

http://www.mediafire.com/download/3o4p0fs6eaxbqtb/Zebedee253setup.exe

Configurando a Zebedee

Zebedee debe ser configurado, sí o sí. No es un programa que se instala y ya funciona. Se lo puede configurar a través de la línea de comandos o a través de un archivo de configuración. Yo prefiero usar un archivo de configuración porque me da mucho más poder, pero en este artículo mostraré solamente como se usa con la línea de comandos. Puedes leer la documentación de Zebedee para saber como usar un archivo de configuración.

Opción 1. El Servidor del Firebird y el Servidor de Zebedee están en la misma computadora

En la computadora que quieres que actúe como Servidor de Zebedee debes escribir:

Captura 4. Si haces clic en la imagen la verás más grande

En el comando ZEBEDEE -s localhost:3050 la opción -s significa que Zebedee se está ejecutando como Servidor, localhost:3050 significa que estará escuchando al puerto 3.050. En otras palabras, que todo lo que envíe a través de ese puerto lo hará en forma comprimida y encriptada.

En las computadoras Cliente de Zebedee debes escribir:

Captura 5. Si haces clic en la imagen la verás más grande

El comando de arriba significa: «Zebedee, todo lo que leas a través del puerto 3.051 debes enviarlo al puerto 3.050 de la computadora que tiene el IP 99.999.999.99» (por supuesto que debes reemplazar los números 99.999.999.99 por los que correspondan a la IP de la computadora donde se encuentra el Servidor del Zebedee).

Para conectarte a una Base de Datos de Firebird debes escribir:

Captura 6. Si haces clic en la imagen la verás más grande

Con lo cual estás diciendo que quieres conectarte a través del puerto local 3051 a esa Base de Datos. Pero como ya habíamos visto todo lo que se envía al puerto local 3.051 se reenvía al puerto remoto 3.050, usando para ello al puerto remoto 11.965.

Local 3.051 —> remoto 11.965 —> remoto 3.050

Opción 2 y Opción 3. El Servidor del Firebird y el Servidor de Zebedee están computadoras distintas

Captura 7. Si haces clic en la imagen la verás más grande

Aquí lo que se le dice es: «Zebedee, utiliza el puerto local 3.050 para comunicarte con la computadora cuya IP es 192.168.0.2 a través del puerto 3.050 de esa computadora». Desde luego que la computadora remota podría estar usando otro puerto, no necesariamente el 3.050.

El comando en el Cliente de Zebedee es el mismo que vimos en la Captura 5.

La conexión a una Base de Datos es igual a como vimos en la Captura 6.

Conclusión:

Si necesitas que tu Base de Datos pueda ser accedida desde Internet entonces es obligatorio que uses Zebedee (o algún programa similar) para protegerla de intrusos. Internet es muy insegura y los hackers siempre están a la pesca de computadoras o bases de datos desprotegidas y aunque creas que no tienes algo valioso que les pueda interesar podrían destruir tu Base de Datos sólo por maldad y porque quieren y pueden hacerlo. Y de paso, para enseñarte una lección relacionada con la seguridad.

Si usas Zebedee entonces el único puerto abierto, el único puerto que puede ser usado para conectarse a Internet debe ser el 11.965 y todos los demás puertos (incluyendo por supuesto el 3.050 ó el que use el Servidor del Firebird), deben estar bloqueados.

Artículos relacionados:

Usando Zebedee con Firebird. Parte 2

Ejemplos del uso de Zebedee con Firebird

Proteger a las bases de datos visibles en Internet

Conexión a través de Internet

El índice del blog Firebird21

El foro del blog Firebird21

Enlaces:

http://www.winton.org.uk/zebedee/

http://www.intitec.com/varios/firebird_zebedee_esp.pdf

Evitando que los mirones averigüen nuestro password en ISQL

Cuando nos conectamos a ISQL todo lo que escribimos es visible para cualquier mirón que esté parado detrás nuestro.

Por ejemplo, si escribimos:

(si haces clic en la imagen la verás más grande)

Cualquiera que esté a nuestro costado o atrás nuestro mirando nuestro monitor sabrá que nos conectamos a la Base de Datos con nombre de usuario SYSDBA y con password 12345678

Si eso ocurre mientras estamos en la oficina de nuestro cliente después que terminamos nuestra tarea, nos vamos a nuestra propia oficina …. y el mirón aprovecha para conectarse a la Base de Datos como SYSDBA ya que conoce el password de ese usuario.

Eso, es un gran riesgo de seguridad. Nunca faltan por ahí los que quieren hacerse de los hackers y estarán más que felices de entrar en un lugar donde se supone no deberían entrar.

Pero necesitamos usar ISQL para realizar nuestra tarea, y tampoco podemos ser tan desagradables como para decirles que se vayan lejos, que se manden a mudar, que se alejen de nosotros porque vamos a escribir algo que queremos mantener en secreto ¿qué hacemos entonces, cómo podemos solucionar este problema, cómo podemos evitar que conozcan el password de SYSDBA o del usuario que usamos para conectarnos?

Afortunadamente el programa ISQL cuenta con una opción -fetch (extraer) la cual nos permite tener guardado el password en un archivo de texto y usará ese password en la conexión.

Por lo tanto lo que debemos hacer es:

1. En un archivo de texto (que puede tener cualquier nombre) escribir el password
2. Al ejecutar el programa ISQL escribir -fetch NombreArchivoTexto
3. De este modo, para conectarnos a la Base de Datos no deberemos especificar el password
4. Si no le mostramos a los usuarios el contenido de nuestro archivo de texto jamás sabrán cual es nuestro password

(si haces clic en la imagen la verás más grande)

En este ejemplo, el password del usuario SYSDBA está guardado en un archivo de texto llamado E:\SISTEMAS\PASS.TXT

Pero ¿cuál es ese password? Ningún mirón puede saberlo, ya que lo que él verá será la captura de pantalla que está arriba.

Nuestro archivo de texto E:\SISTEMAS\PASS.TXT puede estar en un pen-drive y de esa manera ningún mirón jamás tendrá la menor idea de cual es el password allí guardado.

Haciendo así nos aseguramos que ningún mirón se entere de nuestro password y además lo hacemos de una forma «políticamente correcta», es decir sin necesidad de ser desagradables con otras personas.

Artículo relacionado:

El índice del blog Firebird21