El proveedor es Verelox. Están trabajando en la recuperación de los datos que se pueda, aunque el personal cree que no será posible recuperar todo. Su página web únicamente muestra un mensaje informativo de lo sucedido, sin entrar en demasiados detalles.
|
etiquetas: verelox , ex-admin 
![Un ex-admin borra todos los datos de clientes y limpia los servidores de un proveedor de hosting holandés [ENG]](https://peta.meneame.net/backend/media?type=link&id=2785369&version=0&ts=1497193986&image.jpeg)
Puedes tener un equipo dentro de la red con un script que haga una conexión saliente por ssh tunelado por http a una pagina web.
Luego utilizas una conexión inversa por el tunel ssh.
Por el tunel inverso metes una redirección ssh para conectarte a un servidor vpn en el equipo del script.
Y voilá estás totalmente dentro de la red y el firewall solo está viendo tráfico http.
El único sistema para defenderse de un admin bueno es un admin mucho mejor.
El problema es que defenderse es ordenes de magnitud más dificil y consume muchísimo más tiempo y recursos que atacar.
No existe seguridad real contra un admin que sepa lo que hace.
En la práctica se depende en un 99.99% de la ética de el que se marcha.
Por suerte la mayor parte de admins por muy enfadados que puedan estar con la empresa son responsables.
Yo he trabajado en unas cuantas y porque no me interesa lo mas minimo, pero por colegas que siguen dentro se perfectamente que siguen siendo las mismas, su rotacion o como se van actualizando.
Lo mas raro de esto, es que la empresa no guardara backups en cinta...que yo recuerde en españa es , casi obligatorio
Saludos
www.youtube.com/watch?v=i_cVJgIz_Cs
Hay dos palabras mágicas: abracadabra y backup.
La gente piensa que con solo nombrarlas ya las copias se hacen solas, no hace falta probarlos ni verificarlos ni revisar los procesos de recuperación. Lo de RPO y RTO lo dejamos para clientes muuuuuuuuy avanzados.
Eso cuando no piensan que unas cintas viejas son un sistema de disaster recovery.
Si tu política de seguridad no está diseñada para lidiar con ello, posiblemente estás haciendo algo mal, y de esos barros estos lodos.
Ciertamente, no me sorprende, y posiblemente en parte se lo tengan merecido por no escuchar a su CSO, no tener CSO o tener uno que no está haciendo lo que debe.
Y es muy común que un admin tenga varios usuarios... en especial si piensa "hacer algo"...
Siempre es una buena recomendación tener al menos dos administradores "paralelos", todas las tareas y programas bajo un control de cambios exhaustivo y, periódicamente revisarlo y auditar el código respecto a lo que haya en producción para evitar que haya sustos. Sobretodo si se va uno de los dos, claro.
Puedes tener un equipo dentro de la red con un script que haga una conexión saliente por ssh tunelado por http a una pagina web.
Luego utilizas una conexión inversa por el tunel ssh.
Por el tunel inverso metes una redirección ssh para conectarte a un servidor vpn en el equipo del script.
Y voilá estás totalmente dentro de la red y el firewall solo está viendo tráfico http.
El único sistema para defenderse de un admin bueno es un admin mucho mejor.
El problema es que defenderse es ordenes de magnitud más dificil y consume muchísimo más tiempo y recursos que atacar.
No existe seguridad real contra un admin que sepa lo que hace.
En la práctica se depende en un 99.99% de la ética de el que se marcha.
Por suerte la mayor parte de admins por muy enfadados que puedan estar con la empresa son responsables.
Con eso quiero decir que un Palo Alto, por ejemplo, te dirá que ve tráfico SSH por el puerto 80, y si lo has configurado bien, nones un default port y bloqueas el tráfico.
Además siempre tendrás al que piensa que vale mucho más de lo que le pagan, lo valga o no. Disonancia cognitiva.
Creo que no lo has cogido, mando tráfico http genuino a un servidor web genuino a través del proxy.
Da igual que tengas firewalls que analicen en capa 7.
¿A que nivel de profundidad son capaces de analizar?
Yo para saltarme el firewall del trabajo (bluecoat) tunelo por el proxy una conexión http que va a un servidor apache y del servidor apache al ssh interno.
Luego hago una redirección a mi propio proxy y la traigo de vuelta por ssh (4º tunel anidado) para tener internet sin bloqueos.
El ssh está en la 3ª capa y el análisis en layer 7 no pasa de la capa http.
Fue muy duro.
No se pueden cambiar esas cosas tan fácilmente.
La etica la tenemos que tener todos, no solo los trabajadores.
Y para todos los que creen que saben como solucionar todos los problemas.
There are two types of ops people: those who have fucked up production, and those who are about to
Clientes que no tienen nada que ver con cualquier conflicto que podría tener con sus empleadores.
Si tu eras un cliente de ellos y tenías tu web, ahora tu web no la tienes más y perdiste todos tus datos, así que si, te jodió "a ti".
Cuando veo que tal empresa aprece en los ranking de empleobasura, ofrecen sueldos por debaja de convenio, o para echar a la gente la mandan a 600km de sus casa para no pagar despido y encima me venden que tiene como clientes a las empresas mas potentes del mercado, me dan ganas de ir a esos bancos y decirles que cualquier dia les puede pasar algo parecido.
Varias distribuciones de Linux, Windows desde el XP hasta el 10.
Muchos clonados y muchos otros configurados a pelo.
También tenemos unos 15000 usuarios.
¿Como me decías que haces la auditoria para detectar conexiones automatizadas/periódicas en este contexto?
Desde un triste Wireshark hasta un análisis de tráfico WAN detallado
Tio, que estamos hablando de casi 14000 equipos.
Todos los casos que expones funcionan si tienes un red pequeña.
pero si se detecta cualquier método, sobretodo corriendo un rogue VPN server interno
De nuevo, ¿como detectas un servidor de VPN con una configuración por defecto de UDP?
¿Tu has hecho alguna vez un escaneo de puertos UDP? Le da un nuevo significado a "falso positivo".
¿14000 equipos con 64535 posibles puertos con usuarios no administrador escaneándolos por UDP?
¿Como preparas una honeypot para alguien de dentro que además es administrador de sistemas y conoce qué maquinas, configuraciones, topología, etc... que hay para los servidores de vpn, switches. proxies inversos, proxy, firewall, etc...?
Donde pongo :
14000 equipos con 64535 posibles puertos
Realmente son 64511 puertos.
Yo puedo hacer que mis operadores o admins tengan acceso a parar o levantar servicios, mientras que les impido borrar nada, o tener acceso a ciertos ficheros de /etc. Asimismo puedo hacer que todo lo que elimine vaya previamente a una copia en un sistema externo.
Además puedo hacer saltar una alarma si alguno intenta acceder a un recurso que no tiene permitido, por ejemplo al nas externo donde estén los backups.
Y eso son solo unos pocos ejemplos. Todo es cuestión de hacer las cosas como corresponde, y limitar a los usuarios para que solo puedan hacer ciertas cosas sin comprometer la CIA (Confidentiality, Integrity, and Availability).
Ser admin no significa tener barra libre de root. Las empresas que lo hacen así están expuestas a problemas, y suelen ser empresas que carecen, por desconocimiento o por ahorro de costes, de departamentos de seguridad competentes.
Pero a nivel de auditoría te puede ayudar que todos los equipos sean instalados con un mismo método; tener equipos configurados "a pelo" puede ser (es) una pesadilla. Con Active Directory y políticas estrictas es fácil capar las máquinas, incluso cambiar las claves del administrador local en minutos a miles de equipos, pero yo, si me quisiese quedar tranquilo ante la salida de un posible admin desleal, optaría por hacer un nuevo deploy de las máquinas. Si se trabaja con escritorios remotos, perfiles en servidor, carpetas remotas de datos, etc... tampoco debería de ser muy doloroso. Incluso es posible arrancar las instalaciones desatendidas de Windows y Linux (o thinclients si la red lo soporta) desde un PXE server por si se quiere hacer de manera automatizada. La norma es que el usuario, cuanto más capado esté, más tranquilo estará el administrador, aunque en el corto plazo le signifique más curro.
Un netstats a nivel local te dice qué hay corriendo en la máquina en ese momento con acceso de red, si hay un proceso (ejecutable) no identificado en una lista blanca, pues por ahí puedes empezar. Otra cosa es que el admin, evidentemente, conozca el proceso de detección y "quien hace la ley hace la trampa". Tal vez un Splunk te pueda ayudar a localizar/trazar rápidamente comportamientos extraños en una gran red.
El honeypot es mayormente para localizar desde dónde y cómo se conecta, y qué es lo que primero miraría o qué haría/ejecutaría internamente. Una muy buena pista para seguir mirando/limpiando el sistema.
Cuando la gente se va??
Yo en el principio de siglo, pasaba uno o dos días de la primera semana del mes "bloqueando" las contraseñas de los que "se iban a ir" (despidos y no renovaciones de contrato) a finales de ese mes.
si, hay que tratar bien al personal. Pero que te traten mal no te da carta blanca para cometer un crimen como venganza
Es una pesadilla
Con Active Directory y políticas estrictas es fácil capar las máquinas
También estamos metidos ahora en esa otra pesadilla.
Y si tienes pocas configuraciones vale, pero si tienes que dar soporte a 200 programas distintos y cientos de políticas de acceso distintas en la red interna como nos pasa a nosotros el Active Directory es tanto una solución como un problema más. Más problema que solución.
Tenemos "administradores" no locales (cliente) que tiene acceso a instalar lo quee les venga en gana en miles de equipos.
Estamos fractalmente jodidos .
Respecto a lo de los usuarios como administradores locales de sus máquinas, está bien si tienen 2 dedos de frente, pero aún así les tienes que formar periódicamente (y acostumbrar a ello) y muchos no tragan por ahí (sobre todo cuanto más arriba están en la empresa); eso sí que es jodido. Por eso lo de sacar a Terminal Server todas las aplicaciones que puedas (sobre todo cuanto más críticas sean), y que en local lo único que hagan sea consultar la web para leer su FB, el Marca, su correo privado y poco más. Y si se quieren poner una herramienta para convertir PDFs a MP3, pues que se la pongan. Y tampoco te olvides de software como Thinprint o Screwdrivers para impresoras; he visto echar abajo un servidor por clientes instalando los drivers de una Lexmark en el servidor, con la opción de configurar automáticamente las impresoras
Obviamente, despues de haberle entrenado para que no le puedan hacer ingeniería social. Y de haber establecido unos mecanismos que dificulten hacerlo.
En resumen, lo que estás consiguiendo es que el acceso root a un sistema en producción levante ruido y tenga que estar justificado.
Saludos
Eso es genial, pero cuando el administrador monta el chiringuito puede poner un backdoor o varios, y te la puede liar cuando quiera, basta que guarde por ahí un ejecutable con el set uid de root, de hecho cualquiera que en algún momento pueda actuar como root por cualquier motivo, te puede plantar lo que quiera, por ejemplo un demonio que cuando se cambia la contraseña le avise y copie su programita y se borre.
Que pasa si se cabrea el que tiene las contraseñas hace un rm -rf /, no tiene que ser informático para encontrar el comando por internet.
Aparte lo que tu comentas puede funcionar en empresas muy grandes, puede que en grandes también, en empresa medias y pequeñas por lo general tienes un departamento de sistemas relativamente pequeño y el mismo que monta el sistema, es el que actualiza, y el que en caso de necesitarlo pedirá la contraseña de root, no tiene recursos para un departamento dedicado a la seguridad informática y como tu dices quien guarda las contraseñas no sabe de informática, así que cuando alguien de sistemas pida la contraseña se la va a dar y todo el protocolo se va al carajo.
Bajo una buena política de seguridad eso no va a pasar, porque cuando el admin termine su trabajo con un servidor, un proceso automático va a hacer una comprobación de checksums de todos los ficheros de la distribución que tenga el servidor que además te va a decir los ficheros nuevos que ha creado. En cuanto ese reporte lo lea alguien de seguridad va a saber que un admin ha dejado algo que no debe y va a levantar la liebre.
Respecto a lo de las contraseñas, en un modo hyper paranoico, puedes hacer que tenga las contraseñas, pero que no tenga acceso. Es decir, conoce las contraseñas para hacer ciertas cosas, pero requiere de un usuario, que no tendrá, para elevar sus privilegios usando esas contraseñas.
Que sí, que es costoso, pero es como se hacen las cosas en el mundo real para evitar que un empleado o alguien de fuera te la lie. Y volvemos a lo mismo, la contraseña de root no se da nunca, bajo ningún concepto, la política de seguridad tiene que permitir que el usuario tenga acceso a lo que requiera, nada más. ¿Ha habido un fallo con las actualizaciones automáticas y te pide root para solucionarlo? De eso nada, le das un usuario que tendrá permiso para ejecutar los comandos relacionados con actualizaciones, y que tenga acceso al /var donde se guardan los paquetes descargados, y poco más. No tiene porqué tener root. ¿Que necesita más acceso que ese? Que lo justifique, y si es verdad que necesita acceso a algo más se redefine esa política en concreto una vez valorado el tema. Estamos hablando de un sistema en producción, la excusa, tengo que "probar" tal o cual no vale.
Miles de grupos en Directorio Activo para políticas de acceso a directorios.Porque a la misma puñetera carpeta tienen que poder acceder o no un montón de gente en montones de grupos. Y como las políticas de creación de directorios se resumen básicamente a lo que le de la gana al cliente, puedes tener 7 subdirectorios anidados vacíos para alojar un puto archivo. Multiplica por 14000 usuarios y calcula.
Tenemos cientos de grupos para acceso a aplicaciones, agrupamiento de aplicaciones etc... porque tenemos unas 200 aplicaciones a las que dar soporte. Sí tantas.
Ahora estamos con lo de gestionar las políticas de seguridad de los equipos desde DA.
Ya nos gustaría tener 100 GPOs, ya.
Nosotros no podemos formar a los usuarios del cliente ni dictarles normas en absolutamente nada que no estime oportuno el cliente.
Y es una administración pública. Así hay que tirar para adelante con lo que quiera el cliente/usuario final y dar soporte en las condiciones en las que trabajan. no en las que serian deseables o lógicas.
De hecho es prácticamente imposible que los operadores trabajen sin tener bastante acceso de administración.
La seguridad ideal depende de un entorno ideal, pero aunque tú controles la seguridad el entorno depende en última instancia del cliente.
Y mientras los ordenadores arranquen el cliente va a hacer lo que le de la gana y no lo que tú le digas .
Luego no existe algo ni cercano a seguro a no ser que tú seas tu propio cliente.
Si das las passwords a alguien para que las "custodie" lo que dependa de esas passwords no va a funcionar.
Cuanto más seguridad quieras a base de que algunos tengan custodiadas las passwords de un sistema, menos sistemas tienes trabajando.
Ese enfoque es totalmente impracticable.
El cliente va a hacer lo que se haya acordado, y si lo quiere cambiar y no razona, es un mal cliente. En parte es trabajo del dpto. de seguridad explicarles que eso no se hace por joder y relentizar el trabajo, es por su seguridad.
Puedo añadir al operador al grupo lp, pero no siempre va a tener permisos de escritura de grupo.
Mañana en vez de la configuración de la impresora será que se ha quedado parada sin completar una actualización por que han reiniciado a medias y necesito hacer un dpkg --configure -a, y pasado será otra cosa.
Adelantándome a tu pregunta, sí en mi empresa de esto se encargan los operadores. No de todos los casos pero de muchos.
y si lo quiere cambiar y no razona, es un mal cliente.
¿Y que hacemos con él, le echamos a la hoguera?
La mayoría de los clientes no razonan y son malos clientes, pero es lo que hay.
¿Por cierto, ese banco tuyo cuantas aplicaciones tenía que usar?
Pero en cualquier caso si es una locura.
De todas formas aunque tuvieses 100 administradores, el problema de las contraseñas sería el mismo.
Además como tu dices, la configuración para la impresora, así como practicamente todo relacionado con las impresoras depende de los grupos lp/printeradmin, dependiendo de la distro.
Si hay que hacerlo a mano, porque por políticas se ha de cambiar a mano desde un backup y no desde el propio cups, se le permite via sudo hacer un cp de un fichero determinado al printers.conf.
Para los paquetes volvemos a lo mismo, puedes definir un usuario que tenga permisos para ejecutar apt o dpkg, pero no al resto del sistema. De todas maneras, que alguien te reinicie un sistema en producción mientras se está ejecutando una actualización es de traca. Yo en este caso sí que sería más restrictivo y pediría explicaciones, en primer lugar que me justifique el reinicio, y en segundo lugar porqué reinicia a X hora si sabe que a esa hora corre el cron de las actualizaciones.
No le echas a la hoguera, te vas a hablar con el de más arriba y le explicas. A ti te han contratado un producto o servicio, si no se puede dar porque hay un cabezón que se enroca en una idea no es problema tuyo, es suyo, ya que está parando la implantación de una política de seguridad. Yo voy a cobrar igual por cada día que esté de brazos cruzados esperando que el tío razone. Y a lo mejor no me toca a mí escalar el problema por el lado del cliente, lo dejo en manos de los gerentes/comerciales del proyecto y me espero a que esté solucionado. Y en un caso extremo en el que mi empresa me diga que no se puede hacer nada, yo no voy a firmar como que he completado el trabajo, y si años más tarde pasa algo relacionado con eso yo voy a estar cubierto y él se va a comer el problema.
En el banco en el que estaba corrían todos los días más de 25.000 procesos, divididos en unas 100-150 aplicaciones de todo tipo y de índole bancaria. Contabilidad, consolidación de saldos, recibos, históricos, domiciliaciones, extractos, firmas, planes de pensiones, fondos de inversión... Te hablo de hace 20 años, ya casi ni me acuerdo de los nombres.
Los ficheros se corrompen porque si tienes 13000 ordenadores que prácticamente se compran al peso a Dell, HP etc... que tienen de media más de 10 años, que se apagan nunca, que tienen poca CPU y menos memoria y corren aplicaciones que necesitan 3 o 4 veces más ordenador, los usuarios se impacientan y ante cualquier problema le dan al reset.
Los ficheros se corrompen por eso principalmente.
Y los ficheros que se corrompen raramente son los que no se usan, son las aplicaciones que siempre están corriendo las que estadísticamente tienen más posibilidades de que se les corrompan archivos.
se le permite via sudo hacer un cp de un fichero determinado al printers.conf.
Tanto da si añades grupos de acceso a un usuario, si le das acceso por sudo, si al final tienes que darle acceso a casi todo tendrá acceso a casi todo.
No le echas a la hoguera, te vas a hablar con el de más arriba y le explicas.
Vale cuando salgas de Fantasia y vuelvas a la tierra hablamos.
¿Alguien más que haya trabajado en un banco que use 150 aplicaciones?
Pues de vez en cuando me conecto a ese RAS solo por ver si esta activo, y alli estoy, dentro de la red y con acceso a los recursos.
Lo mas cachondo es que desde entonces han tenido que cambiar el rango de IPS en varias ocasiones y han tenido que actualizar las version del RAS si o si.