Por jonsito
En mi trabajo como chichopo no es la primera vez que algún cachondo me dice eso de "Yo no he sido, no estaba, no puedes demostrar nada". Algunos negacionistas recalcitrantes, cuando les contesto mostrandoles las huellas que han dejado en el registro de logs del sistema, me contestan "Sigues sin poder demostrar nada: el log se puede falsificar"...
... Y tengo que agachar las orejas. Efectivamente: los ficheros de log que se generan en Unix/Linux se pueden borrar, editar, modificar... (estoy asumiendo que tengo rol de chichopo). Por ejemplo: los rootkits editan de manera rutinaria el registro para ocultar sus actividades
No solo eso; conozco el caso de una empresa (grande, Muy Grande) a la que le hice un trabajito (una aplicación informática, malpensados), y que ponía en el pliego de condiciones que el registro de eventos fuera editable.... (joer, en manos de quién estamos...). No: no era Telefónica, pero casi.
Y me surge la pregunta: ¿Existe algún medio de aplicar técnicas de PKI para firmar digitalmente un registro de eventos de manera que se pueda certificar que solo ha sido modificado por el syslog?
- No me vale con firmar cada evento que se genera: si bien los eventos no serían modificables, el atacante podría simplemente eliminar los eventos delatores. Lo único que se consigue con este procedimiento es que no se puedan añadir o modificar eventos, pero sí borrarlos...
- El método alternativo consistiría en calcular la firma sobre registro de logs completo: a cada nuevo evento, se recalcularía y firmaría el hash. Este método podría ser factible en entornos pequeños, pero en mi trabajo, donde tenemos centralizado el registro de logs de _cientos_ de equipos, el cálculo de firmas sobre ficheros de megabytes se convierte en una pesadilla para las pobres CPU's....
- Se me ocurre una tercera vía: recalcular y firmar el hash obtenido a partir del evento generado y del hash anterior. La carga de CPU por cada evento generado sería despreciable, pero el proceso de validación del fichero de log puede ser demencial: calcular el hash del hash del hash del hash... evento por evento y así en ficheros de _miles_ de entradas
¿Alguna otra alternativa?
¿Tiene realmente sentido la certificación de un registro de eventos?
¿Está patentado? Si no es el caso, me lo pido... :-)
¿Existe algún sistema de syslog que lo contemple?
¿Qué intereses ocultos puede tener una empresa para que pida que los eventos se puedan falsificar editar?
Juan Antonio
Sgned Syslog
RFC12 Noviembre 2010 - 12:44pm
No he mirado en profundidad que necesita para ser implementado, pero quizas podrías echarle un ojo al RFC 5848
recuerdo haber usado
chilcano2 Noviembre 2010 - 9:12pm
recuerdo haber usado una función HMAC para garantizar la integridad de los logs, no era perfecto, pero servía.
googleando he encontrado esto (Logs Security & Integrity - http://www.softpanorama.org/Logs/log_security.shtml):
1. centralizar los logs
2. modificar o usar un demonio "confiable"
saludos
Otra alternativa
r0dr129 Octubre 2010 - 5:48pm
Nuestro enfoque (basado en una directiva/recomendación europea) es tener unos gatherers de la información, que la recogen y la envían al servidor central donde se filtra por importancia, y se firma electrónicamente con sello de tiempo. El acceso a dicha información está lógicamente restringido, y su alteración invalidaría la firma electrónica.
En Bit4id tenemos un producto para hacer exactamente esto, llamado smartLOG.
Si queréis más información, estaré encantado de atenderos.
O bien se me escapó algo o ...
xiscu29 Octubre 2010 - 5:26pm
... bien no es, ni con logs, ni con 2 máquinas, ni con hash, ni con impresoras ni nada por el estilo, en principio, demostrable ya el individuo en qüestión dice que el administrador falseó los logs ... para mi es como un ataque 'man in the middle' donde el administrador manipula y genera lo que quiere. Él es el root de la máquina y hace lo que quiere. O no?
Aún y así creo (y dejando de lado que el problema se trasladaria al lado del hardware: teclado o input) se podría (mejorar) ejecutando el sistema en un "cloud" o una "máquina remota no controlada por la própia empresa o el administrador". Los logs se generarían en el sistema remoto ...
Un Saludo
xiscu
Depende ....
segurah229 Octubre 2010 - 4:44pm
Primero, la pregunta que me haría es que es un syslog certificado.
Opción 1 : Un archivo de registro de eventos donde "están todos los que son y son todos los que están", para el cual exista un procedimiento informatico que permita verificar su integridad.
Opción 2: Opción 1 + que certifique quien se encuentra en el sitio remoto generando el evento.
Pienso que la Opción 1 es de fácil implementación empleando PKI, WORM, almacenaje remoto, quizás dispositivos HSM, bases de datos cifradas. En fin, tanto como la imaginación y la razón de.
La opción 2 la veo tomada de los pelos, exigiría de alguna manera que quien genera el evento lo esté haciendo con un certificado digital, a fin de evitar el no repudio. El hacker que lo haga dura 1 minuto como hacker ...
Bajo mi punto de vista un syslog "seguro", "certificado", "integro" solo sirve para 'asuntos internos' dado que el valor de prueba legal es escaso o nulo porque no puedo certificar quien está del otro lado.
Dentro de los asuntos internos la principal utilidad es para ubicar fisicamente al atacante e ir por el con todo el aparataje legal y fuerza publica (allanamientos, etc etc) una buen grupo de analisis forense podría, una vez ubicado su equipo probar que se hizo tal o cual transacción desde él.
Enviarlos a un entorno seguro totalmente certificado.
Urk29 Octubre 2010 - 4:38pm
Hola a todos.
Aunque no sólo se utiliza para los registros, en el entorno militar, se utiliza un entorno seguro totalmente certificado (C3, Tempest, etc...), donde se "envía" todo lo que se quiera almacenar fuera del alcance de miradas ajenas.
Cuando digo fuera del alcance, hablo literalmente, puesto que este entorno certificado está separado del resto mediante un "Diodo de datos", que sólo permite la entrada de datos, no hay comunicación en el sentido opuesto, ni para validar la recepción del paquete. Cumple la premisa de que el único Systema seguro es el desconectado...
A este "bunker", se envían tanto copias de seguridad de systemas críticos, como syslogs o cualquier información de la que se busque la "integridad absoluta". Es decir, lo que se persigue es, que si los systemas externos caen o son modificados, poder tener la información integra y poder restaurarla. Cualquier solicitud de restauración se cursa a través de un Oficial de operaciones, que es una persona, que nos devuelve un soporte con la información solicitada.
Extrapolando todo esto a la cuestión original, si ese oficial de operaciones fuera externo a la empresa auditada y tuviera el nivel de certificación suficiente mediante las auditorías externas que se han mencionado antes, creo que sería fácilmente creíble, por supuesto, esta solución no cumpliría con el requisito del pliego de condiciones mencionado al principio, puesto que en el SLA con la empresa externa, no estaría la posibilidad de "Editar" los registros, sino más bien todo lo contrario ;-)
La legislación actual está en pañales respecto a esto, se toman por bueno casi cualquier registro que tenga timestamp.
Pero si el acusado es un poco hábil, puede demostrar la invalided de esas pruebas como ya se ha comentado.
Un sistema externo, auditado y certificado por entidades acreditadas, totalmente ajenas a la empresa demandante, tipo Common Criteria, ISO, etc. Debería ser suficiente para que judicialmente esa prueba fuera irrefutable, sobre todo si se acredita fehacientemente, la imposibilidad de edición de los logs, en el proceso.
Pero, y como todo en esta vida, también tiene peros, incluso en el caso de hacer un syslog automático redirigido a este systema externo, se me ocurren varias formas para "editar" esos registros "en vuelo".
En fin, que dependiendo del nivel de seguridad que queramos, así tendremos que invertir.
Sólo un aclaración, el "diodo de datos" no es un FW configurado con una regla de todo pasa pero nada sale. El "diodo de datos", que existe y que al menos la NC3A y otra empresa Española lo fabrican, tiene entre sus funcionalidades, el "Air Gap", para asegurar su correcto funcionamiento. Está diseñado para funcionar como un diodo.
En cualquier caso, un tema interesante... Si alguien tiene tiempo y dinero, montamos la empresa para dar servicios externos!! ;-)
Un saludo a todos
Write-Once Read-Many File Systems
davidrf28 Octubre 2010 - 9:15pm
http://www.fsl.cs.sunysb.edu/project-wormfs.html
Write-Once Read-Many (WORM) storage is useful for immutable versioning and secure logging, where you wish to record information that an attacker can not modify. One common WORM media is a CD-R, which can not be rewritten, but CD-Rs are slow and do not allow data to be appended. WORM tapes may be appended to, but do not allow fast random access. WORM disk drives, are disk drives with modified device drivers or firmware that does not permit data to be re-written. The advantage of WORM disk drives is that random reads and appends are both fast operations. This project explores how to create a file system that is suitable for a WORM device.
Current file systems rely on re-writing information (e.g., the last block of a file on append or directory blocks when a new file is created), but if data is written to the WORM device, then it can not be changed. An auxiliary read-write device can be used to increase random access performance (e.g., using standard disk data structures that rely on random access writes). If the read-write device is tampered with, the entire file system could be reconstructed from only the sequentially written data on the WORM device. Part of the investigations involve which parts of the WORM abilities should be performed in the file system and which parts should be in disk device driver. Also, the trade offs between flexibility and complexity of the device driver will be explored (e.g., append only drives vs. append only partitions).
Write-Once Read-Many File Systems
caxorrin31 Octubre 2010 - 2:17pm
Hola buenos días.
Os dejo enlace que versa sobre los mismo discos WORM. Espero que os sea util, como idea.
http://emc-centera.com/more-about-emc-centera.htm
Un saludo
Caxorrin
Igual digo una chorrada pero,
Rosenkranz28 Octubre 2010 - 8:35pm
Igual digo una chorrada pero, ¿y crear una partición cifrada donde el sistema guarde los logs?
Hay soluciones
Calario28 Octubre 2010 - 6:30pm
Ayer en ENISE en León se habló de este tema.
Puedes contactar con Joan Marc García de kinamik que se dedican a cosas de éstas.
Si firmar el log entero no es viable
anv28 Octubre 2010 - 4:22pm
Si firmar el log entero no es viable porque es largo, lo que queda es firmar cada registro. Para evitar que te borren un registro se los puede numerar. Siempre lo podrán borrar pero quedará la huella. Y al final de cuentas, firmado o no firmado, siempre sepuede borrar el log entero y así quedan menos huellas aún porque si de todas formas van a descubrir que borré algo, mejor que no sepan cuándo es que hice lo que quiero ocultar, es mejor borrarlo todo que borrar un solo registro.
Haberlas, "hailas"
Liso28 Octubre 2010 - 12:03pm
Haberlas, "hailas" como las meigas :P
No puedo comentar mucho, pero si existen soluciones comerciales que lo implementan:
http://bitacora.s21sec.com/?sec=34
Rumores
caxorrin28 Octubre 2010 - 11:43am
Hola buenos días a todos.
Creo que ya se ha hablado de algo similar un poco más arriba. En una empresa en la que trabajé tenían pensado para guadar datos de autitorías comprar unas cabinas de discos de alta capacidad en las que no se permiten ni modificaciones ni borrados. Creo que esta solución podría valer, pero econonicamente no es muy rentable.
Un saludo
Caxorrin
Metodo vieja escuela
ninHer28 Octubre 2010 - 8:16am
Eso de modificar los logs es una cosa muy feita (como diría Flanders) A grandes males, grandes remedios. Un syslog certificado old style: webcam + keylogger
Respuesta errónea, conclusión acertada
Andy28 Octubre 2010 - 1:00am
Tienes un problema más grande que asegurar la inviolabilidad de los logs.
Técnicamente al presentar los logs como evidencia no estás demostrando que la persona en cuestión haya hecho lo que pone el log, sino simplemente que alguien utilizando tal usuario y tal IP hizo tal o cual cosa. La diferencia puede ser sutil, pero existe.
Claro que si el usuario en vez de responderte eso te responde que los logs pueden ser adulterados, entonces desconfía. En vez de defenderse, confiando en la evidencia que le presentas, te acusa a tí.
Con respecto a los logs en sí, envíalos a múltiples máquinas con varios "@ip". Dependiendo de tu organización, puedes enviarlo a un servidor de auditoría, uno de RRHH, uno de seguridad, etc. Idealmente no deberías tener usuario en ninguno de éstos servidores, que deberían estar en CPDs separados a los que tú no tengas acceso o al menos en sectores con control de acceso dentro del CPD y otra vez, tú sin acceso.
Ante un conflicto, se pide a TODOS los administradores de las máquinas de destino que envíen sus evidencias.
De esa forma, para adulterar un log deben confabularse varias personas de departamentos distintos, que gestionan máquinas distintas, etc.
Un saludo,
Andy
Ese es el segundo problema
jonsito28 Octubre 2010 - 2:08am
Pero yo me refería al primero: sobre el cómo garantizar la validez judicial de un registro de logs.
He tenido varias experiencias al respecto. En todas ellas, como encargado técnico del marrón tenía que preparar las "trampas", garantizar los registros... y hasta donde podía, identificar al culpable. Pero a la hora de la verdad, siempre había que pillar al malo en el mundo real(TM) y con las "manos en la tecla" para poder conseguir alguna sanción efectiva
Una salida habitual, (aunque no sé cual es el alcance judicial real) es que todos los posibles usuarios firmen algúna especie de "contrato" por el que asumen la responsabilidad por el uso que "alguien" haga de sus cuentas y recursos
En fin, espero no tener nunca que ir con el listado en mano ante un juez... aunque sería toda una experiencia :-)
Old fart ramblings
Andy28 Octubre 2010 - 10:01am
Puedes tener los logs super-certificados, sellados, autenticados por notario y custodiados por guardia jurado. Eso no implica que el usuario sea culpable.
Hay que analizar los logs.
Te cuento 2 casos:
El primero, una directora pidió que despidan a un empleado porque le había enviado un email de contenido sexual. Consultamos los logs y efectivamente el email había salido de su buzón, el que sólo había sido accedido por ese usuario. Otra cosa que mostraban los logs es que en ese mismo minuto, el usuario había enviado más de 100 correos similares a otros usuarios. Como lo estás sospechando cuando analizamos su PC tenía varios virus y gusanos ejecutándose. El usuario hacía varios meses que había deshabilitado el antivirus porque "le iba lento". Veredicto: inocente de enviar correos subidos de tono, pero culpable de incumplir las políticas de la empresa con respecto a los antivirus.
El segundo, hace tiempo ya, fué el análisis de unas de las primeras "cajas negras" que se comenzaban a implantar en los camiones de logística de una importante cadena de supermercados. El software de control había detectado que un camión había excedido la velocidad máxima permitida, aunque el conductor lo negaba. Cuando tuvimos acceso a los registros fuente (antes de analizar) vimos lo siguiente:
El camión pasó de 40Km/h a 135Km/h por 3 segundos y luego volvió a 40Km/h. Un poco difícil para un camión de varias toneladas. Nuestra conclusión es que el sensor estaba instalado en una de las ruedas con tracción y que la misma patinó momentáneamente sobre una superficie mojada o sobre barro. Hubo que modificar el software de análisis para tomar en cuenta estos casos. Veredicto: conductor inocente.
En ambos casos los logs eran originales y sin adulterar, pero la "culpabilidad" de los usuarios afectados por los mismos no era tal.
Un saludo,
Andy
Creo que la solución
menos_1627 Octubre 2010 - 11:19pm
Creo que la solución que buscas consiste en programar el syslog para que no genere un log si no 2, siendo espejos, el segundo de ellos estaría cifrado (algo tan simple como convertir el código de página podría resultar) y el original manteniendolo en texto claro como simple cebo para los listillos.
Una sencilla comparación con el log original te dirá si ha sido modificado.Se me ocurren otras posibilidades pero básicamente esa sería la idea.
no se.... se me ocurre ... que....
Geek Insane27 Octubre 2010 - 11:03pm
Pues no lo sé, se me ocurre lo siguiente... (que alguién me juzgue de loco... xD) jaja
que el demonio de syslog tuviera la capacidad de utilizar certificados SSL para escribir el archivo syslog (es decir que el archivo viviria encriptado en el HD), y no seria legible a traves de ningun mecanismo, si no es mediante el mismo syslog que tuviera la posibilidad de hacer un tipo show, que muestre los registros en texto plano pero unicamente de tipo print (sin posibilidad de modificar/eliminar)
así tendriamos la certeza de que si esta escrito en el archivo es porque syslog lo escribio y no una tercera persona...
Que opinan?
Hay varias opciones
enxebree27 Octubre 2010 - 9:40pm
syslog-ng
Sobre todo la versión premium de pago, que te permite cifrado y timestamps externos.
el mismo rsyslog que se emplea en varias distribuciones (e.g. Ubuntu) te permite por ejemplo enviar el log a otro servidor (a través de protocolos seguros) e incluso emplear una base de datos externa (sobre la que tu controlas los permisos y puedes evitar que solo se pueda escribir, no borrar), etc...
Aquí tiene un buen ejemplo de lo que se puede hacer con rsyslog, http://blog.e2h.net/2010/01/03/instalando-un-servidor-de-logs-rsyslog-ph...
Antes estaba también el modular syslog, pero hoy en día es un proyecto discontinuado...
Y alguna que otra solución comercial, pero con el rsyslog te apañas de sobra si lo configuras bien.
Saludos
pero...
ahernandez27 Octubre 2010 - 10:51pm
...una acción delictiva o ilícita se puede desarrollar a lo largo de varios días, es decir, recogido en varios ficheros consecutivos de log.
Firmando e introduciendo un timestamp se puede demostar la cadena de custodía del log, pero no la secuencialidad de dos ficheros de logs diversos (pudo haber sucedido algo entre medias y no haberlo capturado). Este es un motivo de pérdida de carga en la prueba pericial informática.
Es por esto que las versiones comerciales de softs que permiten este tipo de funcionalidades se recurre a los mencionados árboles de merkle.
Está inventado, patentado y comercializado...
ahernandez27 Octubre 2010 - 6:13pm
... y además por una empresa española y algunas americanas.
No es un tema excesivamente complicado.
Os doy unas pistas: árboles de Merkle con hashes encadenados y hashes raíces publicados en un medio auditable y no modificable.
Yo había pensado...
jonsito28 Octubre 2010 - 12:28am
... Un sistema de hashes encadenados (cada registro utiliza su propio hash y el del registro anterior), pero tenía el inconveniente de que la validación de un registro implica la validación de todos los anteriores (el algoritmo es secuencial), y lleva su tiempo...
No se me había ocurrido la idea de hashes encadenados en árbol, pero tiene mucho sentido: con solo log2(n) cálculos de hash puedes validar la n-esima entrada de un fichero de log. Tan simple como recorrer un árbol de búsqueda binaria calculando el hash en cada bifurcación
Con este sistema es extremadamente rápido adivinar si ha habido inserciones o borrados (basta con comprobar el hash del último registro). Pero para detectar modificaciones hay todavía que ir registro por registro comprobando las firmas de éstos
¿Seguro que está patentado?. !cachis! porque es un algoritmo extremadamente simple y efectivo....
A pesar de todo un problema persiste: hay que garantizar la copia de respaldo del log, para evitar que "el malo" destruya el registro sin más que borrar una entrada de éste. Me imagino que aquí es donde entra el SSL y el servidor de BBDD remoto...
Gracias por las pistas.
Aquí puedes ver documentación
enxebree28 Octubre 2010 - 12:52pm
Aquí puedes ver documentación sobre el tema del empleo de los Hash Trees:
La primera referencia que he visto sobre el tema es del 2005, por unos investigadores japoneses
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1495955
y expuesto en una conferencia en el 2006
http://www.springer.com/computer/communication+networks/book/978-3-540-6...
Hay un paper de Scott A. Crosby y Dan S. Wallach de la Rice University, qye puedes descargar aquí:
Efficient Data Structures for Tamper Evident Logging
del que puedes bajarte una presentación en PDF de una conferencia en el 2009
www.usenix.org/events/sec09/tech/slides/crosby.pdf
y su tesis doctoral que trata más ampliamente el tema
http://www.cs.rice.edu/~scrosby/pubs/crosby_PhD_Thesis.pdf
Y si, hay patentes ya del 79 (US Patent number: 4309569) del propio Merkle para generar firmas digitales mediante Hash Trees, y patentes de IBM aplicando la tecnología a registros en BDD y de otras empresas en transacciones financieras... vamos que hay patentes y tecnología previa...
Pues es una putada, a pagar tocan... y yo que era feliz con mi rsyslog...
Saludos
En Costa Rica
Sebastian Elizondo27 Octubre 2010 - 5:52pm
Solamente es necesario un perito o un Notario Publico que certifiquen los registros y ya son validos.
Pues
usrdxt27 Octubre 2010 - 4:59pm
tantos y tan variados que probablemente no haya suficiente espacio en este recuadro para describirlos ;)
Todo en uno
opalenzuela27 Octubre 2010 - 4:58pm
Ahi va una idea, a ver que os parece (se me acaba de ocurrir leyendo los comentarios, por lo que puede tener errores o ser incompleto).
Los logs, en sistemas en explotación, hay que rotarlos de vez en cuando. Desde mi punto de vista, ése es precisamente el momento donde debería introducirse esta especie de "certificación". Al rotar un log:
Con este mecanismo no estamos transmitiendo información privilegiada a nadie, pero sí estamos dejando en manos ajenas la prueba de autenticidad de unos archivos poco útiles, pero muy valiosos. Además, el servicio no supone una carga significativa para esta empresa externa, que solamente debería preocuparse de mantener digitalmente seguros (copia de seguridad, disponibilidad, integridad...) un montón de pequeñísimos archivos.
Como idea de negocio, tal empresa podría ofrecer tal servicio de forma gratuita, y solamente cobrar por la solicitud de confirmación de algunos datos (lo que sucedería en el caso que fuera necesario justificar la autenticidad de un archivo en un juicio) y tal vez por el alta, ya que debería asignarse a alguien como responsable, lo que supone algún tipo de coste administrativo.
La firma en el logrotate....
jonsito27 Octubre 2010 - 5:37pm
Ya se me había ocurrido.
El problema es que dicho procedimiento no evita la inserción/modificación/borrado del registro mientras está "vivo"
Yo lo que buscaba era alguna forma de acreditar que incluso en una máquina comprometida" el (los) fichero(s) de logs solo lo(s) toca un syslogd "patanegra-bendecido-certificado"
Una forma podría ser configurar el syslog para que en lugar de ficheros atacara por SSL a una base de datos custodiada por un "tercero de confianza": el registro ya no solo no estaría "en claro", sino que ni siquiera estaría en nuestro poder (y por tanto al alcance del atacante). Pero hay tantas cosas que pueden fallar en esta cadena... sin ir mas lejos: "el malo" puede bloquear la conexión, con lo que ni siquiera existiría log....
Lo de la copia en papel o en CD... bueno, con la sentencia del tribunal europeo sobre el cánon, y tratándose de una empresa, puede ser cuestión de estudiarlo...
¿Alguien conoce jurisprudencia sobre la validez que se otorga judicialmente a los registros informáticos de eventos?
¿o necesitan de una certificación ISO previa sobre la validez del procedimiento, y de un "perito" que acredite la veracidad documental del registro?
¿hay alguna directiva de la UE al respecto?
Gracias por las sugerencias
Juan Antonio
Mala solución tiene
sag27 Octubre 2010 - 4:04pm
Mala solución tiene.
Lo único que se me ocurre seria para dar mas autencidad a tu datos es lo siguiente.
1- Pasar una auditoria externa de tu sistema periódicamente, certificando que no tienes ningún problema de seguridad.
2- Tener muy controlado-documentado los procesos y usuarios, que tienen acceso a dichos fichero.
3- Implementar algún tipo de autencación mas segura, como puede ser mediante SmartCard o similar.
Esto daría cierta validez, aun con todo esto siempre queda la posibilidad de malas practicas.
Esta es mi opinión si alguien puede aportar algo más, se agradecería
Se me ocurren varias formas
salarin (no verificado)27 Octubre 2010 - 3:54pm
hola, se me ocurren varias formas de conseguirlo.
1. Mantener otro registro "copia" en una maquina independiente, controlada por otra gente. Puede ser un servicio externo al que se envian los logs por un canal seguro. El problema es si se corta el envío, a partir de ese momento ya no habría copia claro.
2. Imprimirlos. Aunque parezca volver a la era analógica, hay que tener en cuenta que muchas leyes siguen siendo de esa era. Lo que está imprimido, si se hace bien, es mucho más fácil demostrar que es auténtico.
3. Guardar los logs en algún tipo de medio no reescribible. Esto es parecido a la solución anterior, sólo que en lugar de una impresora pueden ser CDs de una sola escritura o algo así.
Todo lo de las firmas y hashes está bien, pero sólo si se combina con algún medio que físicamente no permita la reescritura. Creo que esa es la clave.
Saludos!
En los tiempos que corren
anv28 Octubre 2010 - 4:27pm
En los tiempos que corren imprimir los logs parece una tontería. Sin embargo yo trabajé en un lugar donde se hacía así y realmente es lo más seguro que hay. Además es cómodo.
De hecho, era tan común que todo saliera registrado que los operadores se conocían el ruido que hacía la impresora, y cuando había un problema se daban cuenta inmediatamente porque al imprimir algo diferente, la impresora hacía un ruido distinto.
Lo de los medios no reescribibles está bien pero habría que grabar paquetes. Tal vez una alternativa mejor sería el log remoto. Podría tenerse un servidor especialmente grabando los logs, y ubicado incluso en un lugar físico inaccesible. Las claves para administrarlo podrían ser secretas y conocidas sólo por el jefe o incluso se pueden generar al azar y guardarse en sobre cerrado. De esa manera no habría mucha duda de que los datos guardados son válidos.
Si sospechas...
Sasha27 Octubre 2010 - 3:41pm
Si tienes sospechas de que algo no cuenta el syslog debes mirar en más sitios:
- last y lastb para los accesos, no descartes ni uno (aunque tenga una sesión de 0 segundos)
- el histórico de los usuarios antes localizados
- cualesquiera otros log como los de SSH si se entra por ahí y están configurados, FTP igual...
Lo digo porque yo he llegado a modificar algún fichero sin que en el histórico quedase registrado, ya que lo hice mediante un comando remoto (remsh o ssh). No quedaba en el histórico pero sí en varios logs. Los cuales pueden ser modificables, todo sea dicho.
Pero en tu caso no he sido yo, ojo. A ver qué va a pasar. Y no fue el syslog.
Y no hablemos de petostes que hemos visto en grandes empresas y sitios oficiales que le crujen al admin por el ancho de banda. Todos hemos puesto los ojos como cabra que se asoma al precipicio y hemos dicho 'mira, mejor no pienses'.
Con mis propios ojos
admin27 Octubre 2010 - 3:16pm
he visto a un señor juez tragarse como cierto un log de texto como si fuera verdad divina impresa en piedra.
Justo el mismo juez que minutos antes había rechazado como prueba las fotos de un investigador privado.
Me temo que con la ignorancia de los jueces en estas cuestiones hemos tropezado, amigo Sancho.