Desde ya les adelanto que los mismos de systemd, se EXCUSARON, con pelotudeces como: "bueno, en realidad eso no pasa, yo no borro mis log" "si te hackean tenes que reinstalar todo" "el analisis forense se hace con un volcado de ram y de disco" "si no tenes medios y es remoto es porque algo tenias mal" "es un error del admin por usar contraseñas debiles". O sea, todas excusas, y saben que no miento me tome el laburo de preguntar y NADIE de systemd me dio una puta explicacion racional. Pasemos al post.
Como habran visto en este post: JournalD Crashea El Sistema , luego de que el log de journald es corrompido o borrado, ya sea por: fallas de hardware, fallas de software (bug) o hackeos, este no se recupera, se cuelga y en el mejor de los casos, tenemos que reiniciar para que vuelva a funcionar, dado que sino el proceso queda como "defunct", cosa que en mi puta vida vi con syslog.
Pasemos al caso de analisis, paso a paso para los mas apurados asi no se pierden:
1.- Tengo un cliente en la India, tengo acceso por SSH, le mantengo sus sevidores
2.- Un dia me llama porque tiene mucha actividad de red y sus admin no saben que es, son medio pavotes
3.- Me meto por SSH y veo que un server recien instalado que usa CentOS 7, tiene un trafico de red UDP enorme asi como 2 conexiones a undernet, el IRC.
4.- Es obvio que algo pasa, quiero mirar el log Y OPS, no tengo log y para colmo, no tengo log desde hace 2 dias, asi que si en 2 dias luego de la intrusion, hicieron una fiesta, yo no me entero, porque? Journald NO REINICIA EL LOG NI EL SERVICIO EN CASO DE BORRADO O CORRUPCION DE LOG, MENOS TRABAJO DE BORRAR HUELLAS PARA LOS CHICOS MALOS
5.- Me pongo a mirar y veo un proceso que consume 99% de CPU, ingado y llego a que si bien se llama watchdog y corre como root, con lsof veo que va a un archivo que no existe y fue borrado, pero aun corre (se puede hacer eso, aviso para los que dicen que no les paso un perlbot y veran)
6.- Me dispongo a mirar las conexiones, netstat -putall o como gusten y veo, la conexion a undernet, otra mas desde una IP de Argentina con una psyBNC y otra de trafico UDP, evidentemente colaron un bot para flood que usan en un IRC.
7.- Como entre? con mi usuario dentro del grupo wheel, synflag, me promovi a root con el password redhat124 que es el password que el pelotudo que instalo el servidor de correo interno usó.
8.- Me perdí 2 dias de logueo desde el incidente, nadie se entero de que mierda paso mientras tanto o sea que quedo literalmente abierto de culo el servidor y sin logueo alguno, y mientras yo hago cosas, como, matar el proceso, cerrar las IP que se metieron y buscar rootkit tampoco tengo log, porque? JOURNALD NO SE REINICIA LUEGO DE MORIR POR BORRADO DE LOG O CORRUPCION DE DATOS DEL MISMO
9.- La solucion de la gente de systemd, me refiero al soporte oficial es que si fue hackeado, debe ser reinstalado, y el log de ahora no importa, ni el anterior, una solucion MUY windows.
Saben cuantos server asi rescate sin reiniciar, que alguno pelotudito script kiddie se metio con un perlbot y facilmente lo sacas sin reiniciar ni reinstalar NADA? pero la gente de systemd, asume que a vos no te pasa eso, asume que sos el 99% que usa desktop o laptop y vas a reinstalar, ahora me pregunto yo, para que tienen pensado RHEL7 ? para correo interno nada mas? que no se les revele un empleado porque tambien los jode......
Lo dejo al criterio del que entienda esto, la falla enorme de journald, que vez de avisar "che loco me borraron el log, me hackearon o me fallo el disco, me reinicio", simplemente muere y deja de loguear, LINDO NO?.
PD: para los que dicen, me importa un carajo, no laburo de sysadmin, ojale que tu ISP o correo use RHEL7 o algo con systemd y tenga que reiniciar por una corrupcion de log, luego no te quejes salamin al ISP, quejate con Red Hat
Como habran visto en este post: JournalD Crashea El Sistema , luego de que el log de journald es corrompido o borrado, ya sea por: fallas de hardware, fallas de software (bug) o hackeos, este no se recupera, se cuelga y en el mejor de los casos, tenemos que reiniciar para que vuelva a funcionar, dado que sino el proceso queda como "defunct", cosa que en mi puta vida vi con syslog.
Pasemos al caso de analisis, paso a paso para los mas apurados asi no se pierden:
1.- Tengo un cliente en la India, tengo acceso por SSH, le mantengo sus sevidores
2.- Un dia me llama porque tiene mucha actividad de red y sus admin no saben que es, son medio pavotes
3.- Me meto por SSH y veo que un server recien instalado que usa CentOS 7, tiene un trafico de red UDP enorme asi como 2 conexiones a undernet, el IRC.
4.- Es obvio que algo pasa, quiero mirar el log Y OPS, no tengo log y para colmo, no tengo log desde hace 2 dias, asi que si en 2 dias luego de la intrusion, hicieron una fiesta, yo no me entero, porque? Journald NO REINICIA EL LOG NI EL SERVICIO EN CASO DE BORRADO O CORRUPCION DE LOG, MENOS TRABAJO DE BORRAR HUELLAS PARA LOS CHICOS MALOS
5.- Me pongo a mirar y veo un proceso que consume 99% de CPU, ingado y llego a que si bien se llama watchdog y corre como root, con lsof veo que va a un archivo que no existe y fue borrado, pero aun corre (se puede hacer eso, aviso para los que dicen que no les paso un perlbot y veran)
6.- Me dispongo a mirar las conexiones, netstat -putall o como gusten y veo, la conexion a undernet, otra mas desde una IP de Argentina con una psyBNC y otra de trafico UDP, evidentemente colaron un bot para flood que usan en un IRC.
7.- Como entre? con mi usuario dentro del grupo wheel, synflag, me promovi a root con el password redhat124 que es el password que el pelotudo que instalo el servidor de correo interno usó.
8.- Me perdí 2 dias de logueo desde el incidente, nadie se entero de que mierda paso mientras tanto o sea que quedo literalmente abierto de culo el servidor y sin logueo alguno, y mientras yo hago cosas, como, matar el proceso, cerrar las IP que se metieron y buscar rootkit tampoco tengo log, porque? JOURNALD NO SE REINICIA LUEGO DE MORIR POR BORRADO DE LOG O CORRUPCION DE DATOS DEL MISMO
9.- La solucion de la gente de systemd, me refiero al soporte oficial es que si fue hackeado, debe ser reinstalado, y el log de ahora no importa, ni el anterior, una solucion MUY windows.
Saben cuantos server asi rescate sin reiniciar, que alguno pelotudito script kiddie se metio con un perlbot y facilmente lo sacas sin reiniciar ni reinstalar NADA? pero la gente de systemd, asume que a vos no te pasa eso, asume que sos el 99% que usa desktop o laptop y vas a reinstalar, ahora me pregunto yo, para que tienen pensado RHEL7 ? para correo interno nada mas? que no se les revele un empleado porque tambien los jode......
Lo dejo al criterio del que entienda esto, la falla enorme de journald, que vez de avisar "che loco me borraron el log, me hackearon o me fallo el disco, me reinicio", simplemente muere y deja de loguear, LINDO NO?.
PD: para los que dicen, me importa un carajo, no laburo de sysadmin, ojale que tu ISP o correo use RHEL7 o algo con systemd y tenga que reiniciar por una corrupcion de log, luego no te quejes salamin al ISP, quejate con Red Hat
6 comentarios:
el problema es realmente preocupante porque, en el ejemplo tuyo pasaron 2 dias. Pero que pasa si pasan 3 meses y nadie se entera?. Osea llegado a ese punto tenes que ponerte a revisar por donde mas han podido andar en todo ese tiempo.
Exacto, pero los de Red Hat no lo entienden asi, les reporte el bug y lo pusieron como "pedido de feature" no como bug. A ver si los demas, no vos abren los ojos de quien es RH, no es sin fines de lucro ni son buenos chicos.
Lo que te paso de alto uso de CPU, es porque SAMBA tiene una falla segun veo con FreeNAS y por eso lleva el CPU tan arriba. Si bien me decis que memoria tenes, no me dijiste el CPU.
Te recomiendo que pruebes con http://www.nas4free.org/ primero, un fork de FreeNAS desde su version 7 y veas que tal va, sino, esta bien lo de centos 7 aunque podrias usar el 6, dado que no usa systemd aun.
Proba esa distro, Nas4free, si seguis teniendo problemas, habria que ver el motivo del alto uso de CPU, y si queres usar Linux, pero queres seguridad, yo recomiendo que uses Gentoo Hardened.
Es jodido si, pero, dejalo, digo, si te anda bien con CentOS 7, esta bien, lo que no quiere decir que yo lo usaria, meteria un CentOS 6, que hasta el 2020 tiene soporte o lisa y llanamente un FreeBSD y arriba el Samba.
Hola Thunder Dac, yo tuve un problema similar y acabé armando un Debian con ZFS para la tarea.
Una nota, se puede usar ZFS sin tener tanta RAM, para un servidor casero es mas que suficiente, sólo desactiva la deduplicación.
Los de FreeNas exageran un poco (y con razón) en la memoria RAM requerida para usar ZFS, sobretodo por que están dirigidos a empresas, para un Nas casero con 5 clientes 2Gb de Ram basta y sobra aún con ZFS.
ZFS en linux también funciona bien.
De nada!
Publicar un comentario