Ataque tipo: Man in the middle
A pesar de que existen herramientas específicas usadas por los pentesters y auditores de seguridad (además de terceros con peores intenciones…) para realizar este tipo de operaciones, vamos a enfocar el proceso paso a paso con el fin de entenderlo y poder atajar sus efectos.
Herramientas como Cain, Nemesis o Ettercap hacen este tipo de procesos/ataques a las mil maravillas, con variantes e ingredientes añadidos, pero la base de un MITM (Man In The Middle), pasa por entender lo que ocurre cuando enviamos algo a otro sistema informático.
Normalmente, las personas retenemos mal una secuencia de números de cierto número de cifras pero nos es mucho mas fácil de retener una secuencia de letras porque le vemos mas sentido.
Por ello los dominios tienen nombres como: google.com
Esta cadena de caracteres (“google.com”), nos resulta mas amigable que un 74.125.230.81
Ese conjunto de números es lo que denominamos IP y todos ya tenemos en nuestro vocabulario común. Más concretamente una IPv4 consistente en 32 bits agrupadas en 4 grupos de un byte cada uno (1 byte=8 bits), de ahí los puntos entre los números. Dado que este tipo de información es tan básico dejaremos que quien precise mas información sobre IPs vaya aquí.
El caso es que cuando introducimos una dirección como “www.google.com” en un programa, el ordenador no tiene la mas remota idea de donde está esa web, equipo, servicio o lo que quiera ser esa cadena de caracteres.
Por ello “pregunta” a otros ordenadores, denominados servidores DNS ago como (entiendase conversación entre ordenadores 
):
Tu equipo: ” -¿Sabría usted decirme la IP de esta cadena que me ha pedido el usuario?“
El servidor DNS: “-Si claro, como no… vaya a la dirección 74.125.230.81 y olvidese de lo que su usuario le ha pedido. Comprobara que pese a esto, su usuario se siente satifecho con lo que usted le ofrece…(porque es lo mismo)“
La cosa es que el equipo “va” a la dirección IP y no al nombre que el usuario ha pedido, porque si bien son lo mismo, podemos decir que el texto es la forma en la que se refieren los usuarios a un determinado sitio/equipo/web/servicio, mientras que los números (IP), es la forma de denominarlo que tienen los ordenadores…
Ahora la pregunta es:
¿Y que ocuriría si el servidor DNS al que preguntas…resulta ser un suplantador del original?
Podría dirigir cualquiera de las peticiones que el usuario efectúa, hacia cualquier otro lugar…
Ese suplantador, es uno de tantos tipos de man in the middle, si bien veremos otros tipos de forma mas profunda.
Este ataque es de fácil realización por várias técnicas, si bien la de modificar la configuracíón del router de acceso a internet del usuario o cambiar las DNSs de su equipo son las mas fáciles y utilizadas.
Sigamos profundizando algo más en la comunicación entre equipos.
Hemos visto que las cadenas de caracteres se transforman en IPs, pero hay pasos adicionales.
Veámoslo con ejemplos.
Si utilizas MS Windows (si usas Linux y no sabes que es una shell…mal lo llevamos…), pulsas inicio, ejecutar y tecleas “cmd” (+ enter), para abrir una de esas consolas negras “que no sirven para nada porque no tienen iconos…:-)”
Si en dicha consola (a la que denominaremos “shell”), tecleas hostname y verás el nombre de tu equipo y si introduces el comando “ipconfig” (ifconfig en Linux), verás la dirección IP de tu ordenador.
Pero hay más…
Si hacemos un ping (simplificando: comando para comprobar que el destinatario responde) a tu propia ip, comprobarás que responde a la petición.
Podríamos decir que la dirección IP es otro número “impuesto” al equipo (como el número de la seguridad social, o del carnét de conducir), si bien no es propio del equipo por construcción.
Hay otro número (hablando en binario), que SI que es intrinseco al equipo y que viene en su “ADN”, pues se le otorga durante su contrucción y se supone único a nivel mundial… “:-/”
A este número se le denomina dirección MAC o dirección física y cada tarjeta de red tiene uno diferente.
Una vez que un ordenador sabe a que IP debe enviar su mensage/peticion/lo que sea…dentro de una LAN (red local) pregunta a dicho equipo por su dirección MAC.
Tu ordenador: “-Oye 192.168.1.23, te importa darme tu dirección física para enviarte los datos?, por cierto, la mía la tienes en mi propia petición“
El otro equipo/router/aparato: “-Si claro, mi MAC es esta: 00:1E:0B:00:2F:3C“
La representación se suele realizar en formato hexadecimal, ya que es mas corto que el mismo número en binario que sería este:
1111000001011000000000010111100111100
Que a su vez corresponde a este otro en decimal (formato numérico al que mas acostumbrado el está la mayoria de NO informáticos…)
129033580348
Así como el protocolo para resolver una IP, en base a una FQDN (Full Qualified Domain Name) como www.google.com, el algoritmo utilizado era DNS… existe otro algoritmo utilizado para resolver direcciones MAC en base a una dirección IP: Se denomina ARP (Address Resolution Protocol).
E xiste una forma de ver las direcciones MAC que un ordenador tiene en cache, o dicho de otro modo, las ultimas y mas habituales a las que ha contactado durante los ultimos instantes. El comando es “arp -a“. Con dicho comando veremos una lista de equivalencias entre IPs y MACs, que usa el equipo para no tener que resolver direcciones que ya haresuelto hace poco tiempo (segundos/minutos dependiendo de configuraciones).
Cualquier trama que un equipo envía, incluye la dirección MAC de éste (así como su IP), y por tanto un simple ping a la IP de un equipo, desencadena la resolución de su dirección física (a no ser que la tengamos ya en memoria, por una transmisión reciente anterior).
Ahora bien, el ataque del que hablamos, se cimenta en este mecanismo de resolución.
Supongamos que desde tu equipo estás conectado a internet mediante un router. Ello implica que tanto router como tu equipo tienen la IP y MAC del otro y de ese modo transmiten datos entre ambos (y tambien al resto del mundo).
Como sabemos, todo lo que se envía, se pasa en un momento u otro a binario (ceros y unos), y por tanto entre ese conjunto de ceros y unos debe estar incluida la información de la IP, la MAC y otros datos. Si sabemos exactamente donde y conseguimos realizar un falseado de los mismos…tendremos desencadenado el ataque y conseguiremos “ver” todo el tráfico que intercambien los equipos atacados (en este caso un equipo y su router de internet).
El esquema quedaría de este modo:
Veamos el proceso paso a paso:
1.- Cuando el equipo víctima y el router, quieren comunicar entre si, intercambian sus ips y direcciones MAC por medio de ARP
2.- Este mecanismo se realiza de vez en cuando para refrescar la información.
3.- El atacante consigue la ip y la mac de ambos (equipo victima y router), por medio de un simple ping a cada uno( u otro mecanismo cualquiera).
4.- Falsea la información de ambos equipos (equipo víctima y router) y ellos mismos empiezan a mandarle la información “creyendo” que
lo hacen a su legítimo interlocutor.
Ahora vamos a la práctica:
El atacante hace un simple ping a los equipos víctima:
Además captura una trama para modificarla:
Esta trama, almacenada en formato “pcap”, puede almacenarse en un fichero y modificarse con un editor hexadecimal.
El atacante creará dos tramas “envenenadas”.
En la trama que , el atacante, mandará al router, cambia la mac del equipo víctima por la suya,( manteniendo la ip del equipo víctima). De este modo cada vez que el router quiera mandar datos al equipo víctima, realmente la mandará a laMAC del atacante y este observará todo el tráfico.
En la trama que enviará al equipo víctima, cambiará la MAC del router por la suya propia, para que el tráfico generado por la víctima y con destino al router, realmente vaya a parar al atacante.
Posteriormente, solo tiene que crear un pequeño script que envíe cada pocos segundos estas tramas a ambas víctimas (equipo y router), porque sino en unos segundos, ellos mismos, mandarán los datos correctos al otro y el ataque cesará. Este envío contínuo de datos manipulados es lo que llamamos envenenamiento por ARP (ARP Spoofing o ARP Poisoning). (para los mas curiosos:el programita “file2cable”, permitirá mandar por la red el contenido de los archivos manipulados como tramas).
La víctima ahora está a merced del atacante que puede ver todo el contenido de sus transmisiones con el router así como cortarlas, almacenarlas, modificarlas antes de que lleguen a su legítimo destino, reenviarlas…
Como contramedidas o forma de protegerse de este tipo de ataque, hay programas y software de seguridad que permite bloquear o avisar ante cambios de direcciones MAC. Hay quienes optan por tener fijas ciertas direcciones como las del router, evitando su cambio sin autorización. Hay varias formas de evitar este tipo de ataques, pero lo primero para ello, es conocer como se efectúa y como consecuencia entender que elementos deben ser vigilados en una red.
Filed under: Networking, Seguridad Tagged: ARP, arp frame, ARP spoofing, DNS, man in the midle, MITM
Refrigeración del centro de datos: ahorrando con conciencia ecológica
Ya son varias las veces al entrar en un centro de datos, me ha sorprendido comprobar como el sistema de “aire acondicionado”, es EL sistema de refrigeración permanente (nótese en determinate EL y no UN…), en configuraciones diversas N, 2N 2N+1…y variantes…
Hay responsables que comentan:
- “Al ser inverter no tenemos picos de consumo y la potencia consumida es proporcional al esfuerzo que se le pide al sistema”. Si bien es cierto, un sistema de apoyo como el que describiré consume Y TIENE UN MANTENIMIENTO DECENAS DE VECES INFERIOR.
Algunos pensarán que hablo de lugares concretos y proyectados con medios escasos pero he visto dicha configuración desde centros privados a algunos de instituciones públicas y cada cual de distínto tamaño y uso.
Hay que tener en cuenta que el coste de la refrigeración de un CPD es muy alto, llegando a ser el 50% de la potencia invertida en el hardware, con lo que cualquier ahorro supone una gran optimización de costes y rendmiento (así como una menor huella ecológica y lo que ello conlleva).
Una de las formas mas prácticas consiste en acondicionar un plenum superior o chimenea natural de la suficiente altura que provoque una aspiración natural del aire caliente y ello reduzca las necesidade de extracción del mismo.
Dado que no siempre se puede disfrutar de este elemento (dependiente de la construcción del edificio), se puede optar por apoyar los sistemas de aire acondicionado con otros de aire forzado desde el exterior.
Mediante cabinas en las que se incorporan ventiladores específicos para este cometido, se toma aire del exterior y se insufla a los pasillos fríos.
Dado que la gran mayoría de noches del año la temperatura es bastante inferior a la de cualquier centro de datos y lo mismo ocurre durante todo el invierno y parte de primavera y otoño… con un correcto dimensionamiento podremos prescindir del sistema de aire acondicionado durante gran parte del año.
Será necesario incorporar diversos sistemas sin gran complicación compuestos en su versión mas sencilla por automatismos gobernados por higrómetros y termostatos de modo que en función de temperatura y humedad se regule la velocidad de los motores de los ventiladores para un consumo menor siempre que sea posible.En versiones mas avanzadas se podrá incorporar control mediante sistemas informáticos, aunque no siempre es necesario.
En cuanto a la regulación de la velocidad, depende de si estos (lo motores de los ventiladores) son trifásicos o monofásicos.
(Se pueden colocar monofásicos haciendo una correcta distribución de la carga entre las fases, lo que a veces puede ser una ventaja)
En el primer caso casi estaremos obligados a incorporar reguladores de frecuencia que modifiquen la velocidad, pero en caso de ser monofásicos, podemos decantar la decisión por reguladores de tensión, mas económicos y de igual resultado.
De este modo el consumo eléctrico del sistema de aire forzado puede llegar a ser hasta un 90% menor al del sistema de aire acondicionado y de uso durante una gran parte del año. En otra buena parte el aire podrá funcionar a una potencia menor siendo apoyado por el sistema descrito.
En función de ciertas combinaciones de datos podemos hacer que el sistema actúe únicamente sobre el sistema de aire forzado, en combinación o solamente el sistema de frío (lease aire acondicionado).
Mejoras a esta metodología consisten en la incorporación de una estación meteorológica en el exterior y relojes horarios que permitan conocer con una previsión de horas la tendencia del tiempo y adelantar el funcionamiento del sistema esas horas cuando sea factible ahorrando otro buen puñado de watios consumidos.
Así mismo recordaré lo ya indicado en otros posts, en los que menciono la gran mejora existente en el consumo cuando se separa totalemente el pasillo frío del caliente.
Por medio de cortinas (usadas habitualmente en sistemas de cámaras industriales de frío), sistemas de metacrilato disponibles en varios fabricantes así como otras técnicas que no pemitan la mezcla de corrientes de aire calientes y frías.
Tapas en las zonas (“Us”) de los racks no utilizadas, así como en los laterales no cubiertos por cables, evitarán reflujos de aire hacia el pasillo frío que calienten el aire que se aporta a los elementos de hardware. Estos reflujos hacen que los sensores de temperatura de los elementos detencten mayor temperatura y por tanto aumenten la velocidad de los ventiladores. Consecuecia: mayor consumo y contamientación acústica del CPD.
El coste de la instalación de elementos e instalaciones descritas es fácilmente amortizable antes de los tres años desde su instalación , lo que demuestra el alto grado de optimización (con respecto al sistema de contar únicamente con sistemas de aire acondifionado).
Filed under: CPD, Empresa & Estrategia, GreenIT Tagged: aire acondicionado, extracción, forzada, green, Pasillo caliente, pasilo frío, Refrigeración, regulador, ventilación forzada, verde
Clusters HA: No solo para empresas con altos recursos económicos
Existen ciertos servicios que tienen que ser garantizados y por ello se designan recursos y medios que permitan obtener un tiempo de inactividad tendente a cero (o sea, una disponibilidad de casi el 100%, ya que la perfección es virtualmente imposible).
Deseamos disponer del servicio en todo momento incluso ante fallos de las comunicaciones o del hardware.
Para ello no hay una única receta y se aplican diversas técnicas que exceden el propósito de este artículo, si bien una útil y que debe ser valorada es la de la construcción de un Cluster HA (high availability cluster).
Un cluster de alta disponibilidad consiste en un mínimo de dos servidores (en adelante: nodos), que ofrecerán de forma conjunta el servicio en cuestión.
Estos servidores se verán como una única entidad (el cluster), que será la que ofrezca el servicio.
El modelo mas básico y sencillo de cluster es el Activo-Pasivo.
En este caso ambos servidores se conectan entre si, para que cada cual monitorice a su compañero, de tal modo que uno realiza el trabajo mientras el segundo queda a la espera, comprobando en todo momento que el nodo activo, realiza el trabajo. Si se da la circunstancia de caida del nodo que realiza el trabajo, el nodo pasivo toma el control y continua realizando el trabajo (pasando de este modo a ser el nodo activo). De cara al cliente/usuario del servicio, solo percibe que el servicio continua ofreciéndose sin tener que ser partícipe del problema o fallo que se ha producido en los equipos que ofrecen el citado servicio.
Normalmente las empresas disponen de redes SAN, que utilizan para ofrecer una o varias LUNs, que permiten que ambos nodos del cluster dispongan de un lugar de datos accesibles por ambos.
Pongamos un ejemplo sencillo:
Supongamos que queremos que nuestro servicio de alta disponibilidad sea un servidor web mediante apache.
El servicio apache, utiliza (como cualquier aplicación), unos archivos de configuración y un lugar donde residen las páginas que servirá a los clientes que conecten a nuestra web.
Si ambos nodos deben poder ofrecer la web, lo mas lógico es que tanto la configuración como las webs estén en uno/varios (olvidemos en este caso la seguridad) contenedores accesibles por ambos nodos.
De este modo cuando uno de los nodos ponga en marcha apache, utilizará la configuración residente en un punto compartido, y por tanto la misma que su compañero. De igual modo las páginas y otros elementos que compongan el site, también podrán ser cargados.
El esquema sería el siguiente:
Ambos nodos del cluster disponen de acceso a almacenamiento compartido
En caso de no disponer de una infraestructura como la mencionada, no todo está perdido. Existen soluciones gratuitas que permiten crear esta base sin costosos elementos como los antes mencionados.
Este es el caso de DRBD, que permite, configurar una partición o disco de DISCO LOCAL de cada nodo de modo que el disco/partición seleccionada para este uso forma parte de una especie de RAID 1 vía ethernet . Dicho de otro modo, cualquier cosa que se escriba en una de las particiones que forman el recurso compartido por drbd, será replicada en la partición/disco residente en el otro nodo y viceversa.
Con este sistema y ante la caída del nodo activo, dispondremos de la información común replicada en el nodo pasivo y por tanto en condiciones de tomar el control. Este sistema tiene 3 posibles modos de réplica (A,B,y C), de los que por seguridad lo mas recomendable es utilizar el C, si bien la configuración del módulo “drbd”, no es objeto actual del artículo, creo importante citar este aspecto ya que una mala elección del modo de réplica puede dar al traste con la información compartida del cluster.
La configuración de DRBD es sencilla y en la web del proyecto hay buena documentación y ejemplos de configuración.
Una vez solventado el mayor problema para montar un cluster HA, sin almacenamiento compartido, sigamos examinando el resto de claves para la realización del cluster.
Los nodos deben estar permanentemente conectados para monitorizarse entre si. Para ello es mas que recomendable utilizar varios medios de modo que la rotura de uno de los enlaces no suponga un problema.
Lo mas económico pasa por la utilización de una tarjeta de red exclusiva para este cometido y ofrecer redudancia de comunicación mediante el puerto serie de los equipos. Partiendo de que la información para la monitorización es poca, la velocidad que ofrece el puerto serie no es ningú problema. Evítese el uso de switches para la unión vía ethernet, siendo la mejor opción un cable cruzado y directo entre las tarjetas de red destinadas a la monitorización. Del mismo modo procederemos entre los puertos serie con el cable apropiado.
Es importante tener e cuenta que el nodo pasivo, en caso de no recibir, señal desde el nodo activo, se pondrá en acción pasando a ser el nodo activo. Aqui surge un problema, ya que podría darse el caso de que el nodo pasivo no reciba el heartbeat del nodo activo por un problema en el propio nodo pasivo (pod´ria averiarse su tarjeta de red y puerto serie por los que transmite el heartbeat…). Si se dá este caso, ambos nodos se pondrían en funcionamiento de forma simultánea con las consecuencias que esto tendría (las mencionaré posteiormente). Para evitar esto, una forma sencilla de averiguar el origen del problema pasa por lo siguiente:
Se pueden configurar los nodos de modo que ante la pérdida de señal por parte del nodo opuesto, el nodo pasivo, compruebe si el problema es suyo por medio de un ping a un elemento externo al cluster que siempre esté encendido (un router, la ip de gestión de un switch o similares). Si el nodo pasivo puede comunicar con el elemento externo al cluster y no con su compañero, el problema probablemente esté en su compañero, mientras que de ser imposible la comunicacion con otros elementos, probablemente el problema sea de él mismo y por tanto NO activase como nodo activo (ya que probablemente el nodo actualmente activo está funcionando correctamente).
La información de monitorización se conoce como heartbeat (latido), consistente en su forma mas básica en la emisión de un ping desde uno de los nodos, que debe ser respondido por el otro integrante del cluster en caso de estár “vivo”.
No es recomendable compartir una tarjeta de red para este y otros usos ya qua la saturación de la misma en un momento dado, podría dar a entender a uno de los nodos del lcuster que el otro no responde por algún fallo. Otras posibilidades pasan por transmitir una frase cifrada que ambos nodos conocen y que aumenta laseguridad del sistema (un atacante con acceso al canal de heartbeat podría hacer pasar un falso ping por el del otro nodo y comprometer todo el sistema).
La siguiente clave consiste en ofertar el servicio vía red mediante la misma IP en todo momento e independientemente del nodo que esté activo en cada instante.
El segundo y vital componente de nuestro cluster será el software heartbeat .
Este software es, en si, el alma del cluster y mediante una fácil configuración consistente en 3 archivos, podemos indicarle:
- IP de servicio (que ip será la que ofrezca el servicio y por tanto ésta se configurará de forma automática en el nodo activo en cada momento. Esta IP no debemos configurarla de forma manual en ninguna tarjeta de red, ya que el software lo hará por nosotros)
- Servicio a clusterizar (en nuestro ejemplo apache)
- Forma de comunicación y heartbeat a utilizar, canales de transmisión (ethernet + pto. serie en el ejemplo)
Con este software instalado y configurado en ambos nodos del cluster solo tendremos que arancarlo como un servicio mas para que automáticamente tengamos el clustern en funcionamiento.
Aspectos a cuidar y tener en cuenta son aquellos que puedar dar al traste con el sistema. De estos quiero hacer especial mención a aquellos que pueden hacer que ambos nodos del cluster se dispongan simultáneamente como nodo activo.
Esto puede ser desastroso, por múltiples factores de los que los mas importantes y fáciles de ver serían:
- Ambos nodos intentarán configurar la misma IP con los conflictos que esto ocasionará
- Ambos nodos querran poder escribir sobre el contenido compartido pudiendo corromperlo
Es por ello que existen elementos hardware que se aseguran de que solamente un nodo esté activo en el mismo instante de tiempo. El problema reside en que nuestro artículo versa sobre clusters para empresas con bajos o casi nulos recursos económicos y por tanto tenemos que sacar de la chistera otro componente de software llamado watchdog.
Watchdog, es un software que se instala en cada nodo y que “automonitoriza” ese nodo.
Si el servicio clusterizado se queda colgado o tiene problemas de servicio, watchdog, reinicia el nodo, haciendo que ya no esté disponible y por tanto el nodo pasivo, puede tomar el control con seguridad. Cuando el nodo activo, vuelve a arrancar, y dependiendo de la configuraión deseada, podrá ser el nuevo nodo pasivo (hasta que su compañero caiga por alguna razón), o volver a notificar al nodo activo que él será el que pase a serlo y requiriendo que su compañero vuelva a hacer las funciones de nodo pasivo.
Filed under: CPD Tagged: alta, availability, claves, cluster, Disponibilidad, drbd, ha, high
Gestión & Sellado de LOGs
El volumen de datos que se “mueve” en un centro de datos, a lo largo de una jornada es ingente.
Es por ello, que la atención del personal se centra en ciertos parámetros, mientras que otros se supeditan a la activación de alguna alarma (cuando se sobrepasa/disminuye cierto límite en un valor como cantidad de datos transferidos por segundo, ancho de banda libre, consumo de CPU, temperatura, velocidad de giro de un ventilador o estadísticas de I/O de un determinado disco).
Toda la información del entorno debe ser almacenada aun cuando no salten alarmas a fin de su posterior uso en análisis de funcionamientos, tendencias, investigación de eventualidades o colaborar con la justicia si así se requiere.
La forma de almacenamiento de los datos suele consistir en ficheros de texto (encriptados o no), en los que se va almacenando la información. De cada evento almacenado se deberá de almacenar fecha, hora, evento (y otro tipo de información variable como origen, servicio relacionado, prioridad, frecuencia de la ocurrencia, impacto…).
Cada cierto tiempo (diferente para cada Log dependiendo de su naturaleza, pues los hay que crecen de forma desmesurada, mientras otros lo hacen a un ritmo mucho mas sosegado), lo correcto es realizar una rotación de estos Logs (hay sistemas para efectuar esta rotación de forma automatizada). Esto hará que podamos buscar la información en ficheros mas pequeños, delimitados entre fechas y con menor riesgo de corrupción de los mismos.
Una vez rotado un determinado LOG, dispondremos de un fichero “normalmente comprimido”, que contendrá la información de un determinado aspecto del entorno entre dos fechas concretas.
La pregunta que surge inmediatamente es: ¿Como saber que dicho LOG no ha sido modificado posteriormente a su rotado y compresión?
Supongamos que alguien comete un fallo en la gestión de la plataforma y en vez de comunicarlo, prefiere ocultar esta acción. Lógicamente precisará eliminar las entradas de log relacionadas con su acción. Para evitar problemas es mejor adoptar medidas que aporten un mayor nivel de seguridad en estos LOGs.
Una forma útil, con soporte jurídico ante posibles usos legales de dichos datos/logs y sencillo de implantar consiste en firmar digitalmente dichos ficheros con un certificado digital que asegure que ante la modificación del log posteriormente a su firma, quede constancia de tal hecho.
La firma digital de cualquier tipo de fichero, permite asegurar que el fichero firmado, no ha sido modificado desde que se produjo la firma y por tanto que no ha sido falsificado o manipulado.
La firma puede realizarse mediante la emisión de un certificado desde una CA generada por nuestra empresa o por una externa.
Es importante saber que para ciertos usos y dependiendo de la ley vigente en cada estado, puede requerirse que la firma se produzca o efectúe con certificados de determinadas CAs “de confianza para el estado” y con sellado de tiempo.
El sellado de tiempo consiste en la inclusión de la fecha y hora en la que se efectúa la firma digital, por medio de la petición de la misma a un
servidor (y no la fecha y horas del equipo en el que se realiza la firma), normalmente aportado por la propia CA. Por tanto de ese modo no cabe falsificación “fácil”, por parte de quien firma los LOGs, en cuanto al momento en que realizó dicha operación.
Por supuesto estos procedimientos no quitan ni sustituyen al correcto almacenado de los Logs, ni a su correcta custodia, o herramientas adicionales que puedan utilizarse para mejorar su gestión, salvaguarda y replicación, pero es una forma válida y adicional de ofrecer una consistencia legal de los mismos así como una solución para la falsificación de estos datos.
Filed under: Seguridad Tagged: Firma Digital timestamping, logs seguros., sello digital
Teléfono de atención a clientes y partners: