Portada
mis comunidades
otras secciones
![Un ex-admin borra todos los datos de clientes y limpia los servidores de un proveedor de hosting holandés [ENG]](https://cdn.mnmstatic.net/cache/2a/80/media_thumb_2x-link-2785369.jpeg?1497193986)
#21:
#20 Lo del firewall no funciona.
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.
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.
#11:
#6
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.
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.
#56:
#54 En mi curro tenemos unos 13700 equipos de todo tipo.
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...?
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...?
#6:
#1 Te sorprendería la cantidad de empresas donde no lo hacen.
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
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
#14:
Una de las primeras cosas que te enseñan en las certificaciones de seguridad es que existen los llamados "disgrunted employees", es decir, los empleados que se hartan y te la lían.
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.
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.
#55:
#52 La proxima vez que antes de contratar un hosting, que vean como tratan a su gente. Que parece que subcontratar consiste en contratar lo mejorcito por cuatro duros.
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.
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.
#1:
Es espectacular que un EX-Admin haya podido acceder y borrar cosas. ¿Lo de cambiar la contraseñas cuando la gente se va sólo lo hacemos en mi oficina? 
#38:
#33 ¿Quién está enviando trafico ssh al puerto 80? Yo no.
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.
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.
Comentarios
#20 Lo del firewall no funciona.
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.
#21 ¿No es más fácil tratar y pagar a los empleados correctamente?
#24 ya estais los rojos queriendo destruir la paz social
#27 Cobarde
#27 "Perseguís a la gente de quien dependéis, preparamos vuestras comidas, recogemos vuestras basuras, conectamos vuestras llamadas, conducimos vuestras ambulancias, y os protegemos mientras dormís, así que no te metas con nosotros."
El club de la lucha.
#24 Sí pero eso es otro tema distinto.
Además siempre tendrás al que piensa que vale mucho más de lo que le pagan, lo valga o no. Disonancia cognitiva.
#24 Solo digo una cosa, eso puede evitar muchos casos pero no todos, no faltará el que no queda conforme aunque le hayan tratado lo mejor posible. Algo básico, hacer las cosas bien no te garantiza buenos resultados, como mucho inclina el azar a tu favor.
#24
#24 Interesante, en https://news.ycombinator.com/item?id=14522181 la discusion ha ido enseguida a si esto era simplemente cosa de derecho civil. En los casos que yo conozco indirectamente, lo que suele haber es un embrollo de contratos y muy particularmente de no-contratos, falsos autonomos y misteriosas clausulas verbales.
#24 un empleado que jode la vida de cientos de personas que no tienen nada que ver no lo quiero en mi empresa.
#49 Joder a cientos!?!? Joderan a la empresa a mi no.
La etica la tenemos que tener todos, no solo los trabajadores.
#50 jodió a todos los clientes de esa empresa.
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".
#52 La proxima vez que antes de contratar un hosting, que vean como tratan a su gente. Que parece que subcontratar consiste en contratar lo mejorcito por cuatro duros.
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.
#55 espero que el día que seas víctima de un crimen cometido por un empleado descontento de alguna de las cientos de empresas que utilizas diariamente (porque por pura estadística, empleados descontentos los tiene que haber) no te quejes
si, hay que tratar bien al personal. Pero que te traten mal no te da carta blanca para cometer un crimen como venganza
#66 Es pura estadística que puedes perder los datos de la nube, ten copias locales.
#55 Cuando repartieron la empatía tú no estabas ¿no? Y cuando repartieron el sentido del realismo tus hipótesis tampoco. Amosnomejodas, pretender que antes de contratar nada con nadie haya que mirar con lupa las condiciones de los trabajadores... y sobretodo que si no lo haces, merezcas que tu negocio se vaya a pique. Tú eres medio psicópata tío.
#21 hombre, ya hay unos cuantos firewalls que analizan el tráfico en Capa7, por ejemplo, Palo Alto Networks, que lo hace nativo, pero es que el resto de firewalls tienen plug-ins para analizar Capa 7 después de una primera pasada por Capa 4.
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.
#33 ¿Quién está enviando trafico ssh al puerto 80? Yo no.
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.
#38 para acceder a un servidor o se hace desde el mismo servidor o desde una PC que solo tenga acceso a la red local -ip previamente autorizado- ...o me estoy perdiendo de algo?
#33 si el túnel SSH es inverso el tráfico es saliente, no entrante. El firewall no puede hacer un carajo si el tráfico saliente está permitido. Lo que se podría es impedir tráfico SSH saliente en un proxy (o firewall de capa 7), pero eso puede traer problemas.
#21 En una buena auditoría cantaría a kilómetro un script que haga una conexión automatizada/periódica desde el interior, por mucho que lo encapsules como quieras. Si cuando todos callan se oye una voz, ahí está la presa. Desde un triste Wireshark hasta un análisis de tráfico WAN detallado. Lo del Firewall, por ejemplo, funciona porque es un proceso que como no sale a ningún sitio no canta hasta que se le llama, como también lo sería un trigger en una BD ante una entrada de datos determinada. También se puede hacer una time-bomb que abra conexión con tu método en una fecha-hora específica, pero si se detecta cualquier método, sobretodo corriendo un rogue VPN server interno, es más fácil saber por dónde va a venir y montar un honeypot para cazar al admin desleal. Si no hay un análisis exhaustivo de integridad de todo lo que se ejecute, estás perdido ante un admin desleal. Aún así, comparto al 100% las 4 últimas frases.
#54 En mi curro tenemos unos 13700 equipos de todo tipo.
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...?
#56 Ya no puedo editar.
Donde pongo :
14000 equipos con 64535 posibles puertos
Realmente son 64511 puertos.
#61 65535? Solo se hexadecimal
#56 Bueno, con ese volumen estás jodido sí o sí; incluso se podrían hacer 2.000 "saltos de alarma" a la hora con 2.000 falsos positivos, sólo por ver cómo pierdes el tiempo hasta que anules dichas alarmas
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.
#64 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
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 .
#67 Siempre puedes, divide las GPOs y demás para que sean lo más atómicas posibles, y segméntalas por grupos de usuarios y departamentos (OUs): olvídate de hacer una única GPO para todo un departamento. Divide y vencerás. Más vale cargar en el arranque 100 GPOs distintas, y depurar 100 GPOs, que hacer una que englobe todo. Verás que al final no supone tanto curro como pueda parecer, es un "sota-caballo-rey". Además en AD tienes multitud de herramientas para facilitarte esto. Y si no tienes usuarios con programas "multimedia" (audio/video/gráficos), pasa todo lo que puedas a servidores de Terminal (RDP); te evitará el cambio de miles de equipos cada pocos años porque el software ofimático ahora come más recursos. Es más fácil y barato meter más gigas de RAM/HD a unos pocos servidores que a miles de equipos, por no hablar del coste de los deploys y la depuración de fallos.
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
#70 Ya hay más de 14000 usuarios en DA
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.
#80 No, si con lo de las 100 GPOs me refería a cuando depuras y haces un RSoP a un solo usuario/máquina. Por supuesto que tendrás miles y miles de ellos, pero muchos serán prácticamente iguales con pequeñas variaciones. La creación de estructuras de directorios y otras mariconadas también la puedes automatizar con scripts BAT, VBS, Powershell, etc... Limitate a exponer maneras lógicas y cómodas para trabajar todos y luego que hagan lo que se les ponga. Documenta, documenta, documenta y procura tener (y hacer ver a los usuarios) que todo está documentado, especialmente las idas de olla contra las recomendaciones del administrador. No desesperes, que seguro que hay gente por ahí, con DDAA mucho mayores y usuarios mucho peores.
#80 Microsoft system center...?
#64 C&P "Bueno, con ese volumen estás jodido sí o sí; incluso se podrían hacer 2.000 "saltos de alarma" a la hora con 2.000 falsos positivos, sólo por ver cómo pierdes el tiempo hasta que anules dichas alarmas" ... Si haces eso, no tienes espacio para correr...mientras te queden piernas Fdo - Un Operador
Saludos
#72
Y ojo, que se me ocurren otras mucho más crueles pero no las publico por no dar pistas a los malos. Si un script-kiddie te la puede liar, un script-granpa puede montarte un infierno
#56 con ese tamaño de corporación, con mucho IPS y un SIEM.
#21 Y todo por ahorrarse un puto sueldo. Que locura.
#88 En realidad no se ahorran uno. Se ahorran muchos.
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.
#21
node.js y un ssh a través de http...
sólo tienes que googlear un poco.
Es espectacular que un EX-Admin haya podido acceder y borrar cosas. ¿Lo de cambiar la contraseñas cuando la gente se va sólo lo hacemos en mi oficina?
#1 Te sorprendería la cantidad de empresas donde no lo hacen.
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
#6
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.
#11 Solo hay que recordar a GitLab hace unos meses y lo bien que funcionaron sus backups...
#11 Los backups son como el gato de Schrödinger. nunca sabes si funcionaran o no hasta que intentas recupera el sistema
#11 #39 El Disaster Recovery Plan más frecuente es el que se describe en la imagen adjunta.
#43 Nosotros tenemos un kill switch plan en caso de que alguien rompa el perimetro de la DMZ.
#43
Veo que sabes de qué hablas.
Y no, no lo digo en plan de coña ... es lo más parecido a la realidad que he visto.
Eso si, cuando pides pasta para mejorar el sistema de backup ..... nadie te conoce.
#39 Los backup son una entelequia, lo único que realmente existe son los restores.
#39 ¿Como que no lo sabes? Un backup NUNCA funciona
#11 Claro, pero ¿y si el admin borra también las backups qué haces?
#90
Para eso se precisa mucho tiempo y conocimiento.
No es que sea imposible, pero si no lo han detectado, es que tienen un problema muy serio en su infraestructura.
#11 si deberían tener backups porque según información de última hora han recuperado ya todos los datos de Holanda, Canadá y Francia.
After investigation, there is no data lost in The Netherlands, Canada and France.
#1 No, pero me consta que tampoco revisáis todos los sistemas para puertas traseras.
#1 Que tuviera las contraseñas no le da derecho a sabotear la empresa, igual que poder comprar un cuchillo en el supermercado no te da derecho a clavárselo a quien tú quieras. Si tienen pruebas de que ha sido él lo más probable es que se tire una temporada en la cárcel.
#13 Joder, pues nada, me voy a devolver el cuchillo al chino
#26 Mejor, con esos cuchillos es más fácil que te cortes tú mismo al intentar usarlo.
#13 falsa disyuntiva. Una cosa no quita la otra.
#13 en españa te puedo asegurar que si tienes las contraseñas legítimamente, poco podrían hacer legalmente, te lo digo con conocimiento de causa y usando contraseñas de administrador cuando me tiraronde mala manera y sin querer pagarme de una empresa, que copie y borré la web. Y por tontos de denunciar me, acabarom indenizandome a mi por encima de lo que les hubiese tocado....
#1 Si
#1 Normalmente el protocolo es desactivar el usuario.
Y es muy común que un admin tenga varios usuarios... en especial si piensa "hacer algo"...
#17 En una empresa "seria" y grande hay que ir mucho más allá. Si el admin piensa hacer algo, lo normal es que tenga varios backdoors durmientes y embebidos en tareas programadas o que se ejecuten durante el arranque de servicios en los servidores. Y, por ejemplo, verificar el log del firewall para ver si se hace port-knocking en una secuencia determinada para abrir un "acceso".
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.
#1 Se hace en casi todas, pero al cabo de un periodo entre una semana y diez años. 😃
#1 si mañana me echan de mi empresa tengo pass y accesos a media España.
No se pueden cambiar esas cosas tan fácilmente.
#1 ¿Lo de cambiar la contraseñas cuando la gente se va sólo lo hacemos en mi oficina?
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.
#1 Hace unos 10 años que me fui de una empresa en la que era sysadmin. Habia montado un RAS temporalmente para que accediese una sede remota que acababa de abrirse y que aun no estaba dentro de la VPN.
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.
El día que un ex-admin de menéame borre todo el karma de los usuarios sí que reiremos.
#7 Yo no sé si podría soportarlo.
Cuando despidas a un admin, sé amable con él.
#3 o por lo menos pagarle es una forma
#4 O sé claro acerca de lo que sabes de él y entrégale una foto de "Kilombero", ese lumpen colombiano que hace trabajos limpios y profesionales a precios módicos. El sysadmin entenderá perfectamente que siempre es mejor rascarse las espaldas mutuamente que tocarse los cojones.
No te olvides de poner el WHERE en el DELETE FROM, salvo que quieras joder a la empresa claro.
#8 o ponlo igualmente.
DELETE FROM users WHERE 1=1;
No solo es ponerlo, es ponerlo y que sea correcto.
Una de las primeras cosas que te enseñan en las certificaciones de seguridad es que existen los llamados "disgrunted employees", es decir, los empleados que se hartan y te la lían.
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.
#14 Como dicen por arriba, cuando es el administrador y sabe lo que hace, defenderse es muy difícil porque es él quien tiene que poner la política de seguridad en marcha. Así mismo, cuando uno es administrador puede hacer lo que quiera, si tiene permisos lo hace directamente, sino, se los otorga y lo hace.
#31 No necesariamente, los sistemas operativos tienen mecanismos para permitir hacer unas cosas elevando privilegios, pero no otras.
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.
#63 Pero tiene que haber un admin por encima del resto y que pueda hacer todo lo que dices. Imagina que ese admin es el que se cabrea.
#68 No necesariamente, el custodio de las passwords criticas se lo puedes entregar a alguien que no tenga ni idea de informática (a un alto cargo de la empresa por ejemplo) y no suponga un potencial peligro.
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.
#71 Si lo entiendo lo que estas diciendo es que un administrador crea todo el plan de seguridad con todos los permisos, etc y luego le da las contraseñas a un tercero, que las cambia y que solo las tendrá pero no hará nada ¿no?.
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.
#73 A ver, volvemos al inicio, hacer las cosas bien y se eliminan estos riesgos.
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.
#71 Todas las password son críticas.
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.
#82 Que es más complicado no te lo discuto. Que es impracticable... desde mi primer trabajo un poco serio allá por el año 98, un banco que patrocinaba un equipo ciclista usaba esta política, contraseñas en un sobre, y te aseguro que los saldos y la contabilidad salía adelante todos los días sin necesitar esas passwords, de hecho, tenía que pasar algo realmente crítico para que se tuviera que hacer uso de ellas.
#63 No puedes hacer que los administradores administren sin tener acceso.
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.
#81 Ponme un ejemplo practico de por qué los administradores y operadores no pueden trabajar sin tener root.
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.
#83 En un sistema en producción se entiende.
#83 Una impresora de un cliente no funciona (equipo Linux) se ha corrompido el printers.conf en /etc/cups pero tengo backup. ¿Como sobreescribo el archivo?
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?
#87 Los ficheros no se corrompen porque sí. Si ha cambiado la configuración es porque alguien ha tocado lo que no tenía que tocar. Ya entramos en un terreno peligroso para un sistema en producción.
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.
#96 Claro que los ficheros no se corrompen por que sí.
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?
#99 Claro que los ficheros no se corrompen por que sí.
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.
Esa es precisamente la definición contraria al ejemplo que me has puesto del printers.conf, que es prácticamente un fichero de solo lectura.
Los sistemas operativos, o mejor dicho, los sistemas de ficheros, tienen mecanismos como el journal precisamente para que eso no ocurra.
Las bases de datos tienen mecanismos como el redo log precisamente para que eso no ocurra.
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.
Tendrá acceso de forma limitada, a lo que se establezca que tiene que tener. Para eso están las políticas de seguridad.
Vale cuando salgas de Fantasia y vuelvas a la tierra hablamos.
Ya te lo he dicho, si un cliente te contrata X, es porque quiere X. Si un empleado de esa empresa te impide hacerlo, hay mecanismos para intentar que se haga, o en ultimo termino, dejar constancia de que no se ha hecho por tal impedimiento.
¿Alguien más que haya trabajado en un banco que use 150 aplicaciones?
Pues seguramente, porque el sistema del que he hablado no está en un único banco, de hecho, ese banco fue comprado por uno mayor e implanto ese sistema en muchos otros que iba comprando.
Si quieres, te buscas en google lo que es el sistema partenon, de donde sale, y vienes y me cuentas. Y ya si quieres, te miras este PDF (http://www.um.es/documents/4156512/4380245/SANTANDER_06.pdf/4034f7c0-3398-482f-94f3-7f0df356783e), buscas partenon, y cuando veas que pone que tiene 150 aplicaciones, vuelves y reconoces que se te va la boquita.
#96 tu ejemplo del cliente está en las antípodas del mundo real.
Si tu empleador tiene que decidir entre tus necesidades especiales como admin y las del cliente, te va a reemplazar por un compañero con la mentalidad de #87 o va a ponerte de patitas en la calle.
El cliente es la vaca a ordeñar, no tú.
#101Mi cliente es real. Ordenador por ordenador, usuario por usuario.
Si tu empleador tiene que decidir entre tus necesidades especiales como admin y las del cliente, te va a reemplazar por un compañero con la mentalidad de #87 o va a ponerte de patitas en la calle.
No son mis necesidades, son las del empleador que hace todo lo que pide cliente por que es una cuenta de muchos millones de €.
El cliente es la vaca a ordeñar, no tú.
¿De verdad trabajas en algo mínimamente relacionado con informática?
¿En España?
Un bonito hombre muerto, si no le doy OK cada X tiempo (por que ya no trabajo alli), haz esto, o haz lo otro.
¿Limpió los servidores? ¿O sea, les quitó las pelusas de los ventiladores y todo?
#18 Los formateó 35 veces.
El holandés borrante.
#91 Hombre, al fin un chistaco. Y la gente ahí arriba discutiendo sobre seguridad y si se puede o no se puede hacer tal y cual, midiéndose las pollas.
Mis respetos a la gente de operaciones que haya tenido que trabajar toda la noche para recuperar el sistema.
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
Si lo hubieran guardado en la nube no hubiera pasado nada
Vendetta
Vamos a ver, joder un servidor desde fuera es muy facil si has sido admin y los que hay dentro no tiene ni flowers...Un hombre muerto, un script con sleep de meses, crear un daemon, incluso una regla que actue cuando le llegue un correo con cierto subject, etc...
#30 Habla bien, se dice Chief Jacking Officer o CJO.
#42 dudo que muchos entiendan tu referencia, pero es genial
En Menéame son todos administradores de redes, o esto como va?
#25 Aquí el que menos es jacker.
#25 antes que esto fuese todo politiqueo rancio de izquierdas meneame era una web sobro todo de tecnologia, la proporcion de gente experta en informatica es bastante alta. Yo no soy sysadmin, mi campo es otro, y he disfrutado leyendo los hilos de arriba, mucho mas que los que ponen a Pablo Iglesias como el nuevo mesias
#97 A mí me gustan las dos cosas.
Que mania tiene la gente de exharle la mierda a otros pa salvar el culo.... que se lo digan a chema alonso con el wannacry de telefónica kajakajakak
entiendo que tomaran acciones legales contra el ex-administrador
#10 Dependerá de las pruebas que tengan.
#12 Y de si pueden demostrarlo..., porque pueden tener pruebas, pero necesitarán demostrar que ha sido él sin lugar a dudas. O se declara culpable o prácticamente se va de rositas.
Bueno, y todo eso que he comentado, teniendo en cuenta cómo se funciona muchas veces en las empresas, que les hablas de backup y recuperación y te dicen que "ya si eso para cuando tengas un rato libre", mejor ni hablamos.
No creo que el caso sea el último ni el único.
#69 Ajá! Muy bien, gracias.
Hay muchas políticas que pueden ayudar, y mucho, pero todo depende de que el nivel de quien se va sea menor que el de quien diseña los protocolos de seguridad, o incluso, peor, del que se queda. Defenderte del exterior es costoso, y es imposible hacerlo bien al 100%. Defenderse de un administrador bueno, que ha estado meses o años dentro, es una tarea muy jodida... Entre otras cosas, porque tiene que conocer el sistema para trabajar con él, y por lo tanto sabe 'lo que hay'. Compartimentar el acceso a diversas partes puede ayudar también, pero no es algo infalible. Una seguridad bien montada es carísima, y casi ninguna empresa se gasta el dineral que cuesta. Y de esos barros, estos lodos.
Ahí ya solo puedes depositar tu esperanza en una buena herramienta de monitoreo de conexiones (como un OIT) para que, si se lo saltan todo, por lo menos quede grabado cada tecla que toque y cada fichero al que acceda para que al excmo juez no le queden dudas de quien y que ha hecho y tarde poco en deliberar la condena.
Ha sido cosa de Wardog....
Viendo un poco los servicios que ofrecían, no eran más que un revendedor de OVH y de I3D. Cualquier empresa de hosting "seria", tendrá al menos aislada la gestión de los servidores por una VLAN privada con acceso por una VPN para los sysadmin. Para mi esto ya no es una cuestión de buena gestión de backups (que también) sino de tener como mínimo un diseño adecuado de operación y mantenimiento de tu infraestructura.
#57 Al leer que estaban trabajando en sus servidores de Canadá y que los de Francia estaban listos pensé en OVH. Ahora tiene sentido.
cuanto tiempo guarda las paginas visitadas en internet tu proveedor de adsl ?
Pues aquí hay un admin, de nombre
Carme, que ni responde a los comentarios en los que te diriges a ella, los vota negativos, va a buscar la noticia de la que hablas para votarla también negativo, y por último, sin razón alguna que lo justifique dice que esa noticia ha caído para hacer el pobre descuento del karma que correspondería, pero que no corresponde porque sus positivos son más de 300 y los negativos no llegan al 10%
dseijo te ruego que intervengas, no se trata de la admín citada, ni desde luego a mí me importa a nivel personal, pero resulta poco serio para una web el comportamiento descrito en el que existe hasta mala educación y un comportamiento tan sórdido, como soez.
Los hechos tuvieron lugar en el día de ayer, esta es la noticia a día de hoy, que inexplicablemente, y pese a haberse anulado continúa figurando como "pendiente": Fraude en la sanidad pública catalana: la Seguridad Social reclama 8 millones de euros
Fraude en la sanidad pública catalana: la Segurida...
vozpopuli.comAbsolutamente inexplicable, aunque tenga connotaciones políticas que afectan a irregularidades e la gestión económica por parte de la C.A. Cataluña.
#16 creo que ese comentario se merece un meneo con todas las pruebas que, seguro, puedes aportar en
buambusub
#16 no sé qué te pasó, pero te digo (y he aviso) que aquí todos se conocen e impera el amiguismo, sobre todo en algunos admin.
#32 Gracias compi, ya sé cómo funciona esto, y le doy el valor que se merece.
#16 Yo la ví comiendose a un gatito crudo, con raspa y todo.
Fue muy duro.
#16 Gracias por el link. Ya he votado sensacionalista la noticia y algunos comentarios que insultaban a usuarios.
#86 jajjajja bon jour jajja