Tal vez sea un poco raro este mensaje, pero hace una hora recibí un correo del sitio donde tenemos hospedado algunos de nuestras instalaciones Moodle, indicando que desde una de las instalaciones se estaba haciendo "phishing".
Lo interesante es que el sitio tiene permisos 555, y en concreto los archivos que enviaban dichos mensajes se alojaron en auth/mnet/
Los archivos, tres en total, uno de ellos tiene el nombre "Citibank-Secure-Update" html y los otros son extensiones php. Revisando el código del primero apunta a https://online.citibank.com
Según me comunican del servidor esto puede deberse a galerías de fotos o carritos de compras. La primera la tenemos, la segunda no.
Espero sea de ayuda para todos.
Por experiencia propia ratifico y amplio los comentarios de Carlos.
En nuestro caso el ataque hacker que introdujo pishing en nuestro sitio moodle hace unos meses atrás dirigía a una supuesta página del banco HSBC (siempre van hacia estás páginas ya que lo que les interés es robar los datos de acceso a cuentas bancarias).
En ese moodle teníamos varios módulos no estándar instalados como la galería de imágenes Ligboxs y la galería de videos Mediacenter inwicast, entre otros.
El atacante introdujo las siguientes carpetas y archivos en nuestro servidor: media/system/css/hsbc/www.hsbc.co.uk
Desde ese momento (en que la única forma de quitar estos archivos maliciosos que se desparramaron por todo el sitio fue formatear el disco del servidor e instalar todo nuevamente desde cero) no hemos sufrido más ataques… pero hemos hecho lo siguiente:
1. Quitamos el alta de usuarios por los usuarios. Ahora los usuarios son cargados manualmente por el administrador moodle.
2. También quitamos botón de acceso invitado y pusimos contraseña en todos los cursos.
3. Quitamos la posibilidad de ingresar etiquetas html y especialmente código (embed) a los usuarios.
4. Recontra protegimos con firewalls, antivirus y antiespywares todas nuestras PCs de administración, y se administra el servidor y moodle únicamente desde ellas. nadie más tiene acceso (muchos ataques hackers comienzan con spywares infectando nuestras PCs).
5. Instalamos el antivirus sugerido por moodle en el servidor -Cleam AV- y LMD (usamos Linux)
6. Resolvimos todos los permisos del servidor: Directorios = 755 Archivos = 644
7. Revisamos diariamente el servidor para ver los “accesos fallidos” y cuando detectamos algún síntoma de acceso hacker bloqueamos el acceso de dicha IP al servidor.
8. Mantenemos siempre actualizado moodle a su última versión estable publicada
Nota: A pesar de todo esto igualmente realizamos comprobaciones “visuales” del árbol de directorios y comparativa de cantidad de archivos para identificar nuevas instalaciones y/o variaciones que nos sugiera que alguien ha instalado archivos maliciosos en el servidor… y hacemos backups diarios de todo!.
Espero esto sirva a alguien más a protegerse y evitar los problemas propios de ataques hackers.
Saludos. Pablo
En nuestro caso el ataque hacker que introdujo pishing en nuestro sitio moodle hace unos meses atrás dirigía a una supuesta página del banco HSBC (siempre van hacia estás páginas ya que lo que les interés es robar los datos de acceso a cuentas bancarias).
En ese moodle teníamos varios módulos no estándar instalados como la galería de imágenes Ligboxs y la galería de videos Mediacenter inwicast, entre otros.
El atacante introdujo las siguientes carpetas y archivos en nuestro servidor: media/system/css/hsbc/www.hsbc.co.uk
Desde ese momento (en que la única forma de quitar estos archivos maliciosos que se desparramaron por todo el sitio fue formatear el disco del servidor e instalar todo nuevamente desde cero) no hemos sufrido más ataques… pero hemos hecho lo siguiente:
1. Quitamos el alta de usuarios por los usuarios. Ahora los usuarios son cargados manualmente por el administrador moodle.
2. También quitamos botón de acceso invitado y pusimos contraseña en todos los cursos.
3. Quitamos la posibilidad de ingresar etiquetas html y especialmente código (embed) a los usuarios.
4. Recontra protegimos con firewalls, antivirus y antiespywares todas nuestras PCs de administración, y se administra el servidor y moodle únicamente desde ellas. nadie más tiene acceso (muchos ataques hackers comienzan con spywares infectando nuestras PCs).
5. Instalamos el antivirus sugerido por moodle en el servidor -Cleam AV- y LMD (usamos Linux)
6. Resolvimos todos los permisos del servidor: Directorios = 755 Archivos = 644
7. Revisamos diariamente el servidor para ver los “accesos fallidos” y cuando detectamos algún síntoma de acceso hacker bloqueamos el acceso de dicha IP al servidor.
8. Mantenemos siempre actualizado moodle a su última versión estable publicada
Nota: A pesar de todo esto igualmente realizamos comprobaciones “visuales” del árbol de directorios y comparativa de cantidad de archivos para identificar nuevas instalaciones y/o variaciones que nos sugiera que alguien ha instalado archivos maliciosos en el servidor… y hacemos backups diarios de todo!.
Espero esto sirva a alguien más a protegerse y evitar los problemas propios de ataques hackers.
Saludos. Pablo
Hola,
Múy útiles ambos posts.
Sólo como sugerencia, en un hosting compartido me parece que es mejor tener
permisos 505 y/o 604, en lugar de 555 y 644 (como se mencionó más arriba).
Lo anterior, para impedir que otros integrantes del grupo de usuarios en el que
nos encontramos tengan acceso (así sea mínimo), a nuestra plataforma.
Por otra parte, yo mantengo el "config.php" ubicado en la raíz de Moodle,
con permisos 404.
Otra cuestión que es importante mencionar es que los archivos de idioma
distintos al inglés se almacenan en la carpeta "moodledata" (puede tener
otro nombre).
Como dicha carpeta debe tener permisos 777 (707 en un hosting compartido),
entonces los archivos de idioma adquieren esos permisos (eso recuerdo).
Como son archivos PHP, entonces según lo que he leído, hay una vulnerabilidad
por ahí, pues se le puede inyectar código malicioso a los archivos con toda
tranquilidad (se tiene máximo acceso y posibilidad de manipulación de los archivos).
En este sentido lo que yo acostumbro es colocar el idioma manualmente
(osea que no lo instala la plataforma, sino que yo lo descargo del sitio
de Moodle y luego lo subo por FTP, pues es lo que he visto que es mejor
en un hosting compartido por cuestiones de quién queda como propietario
de la carpeta).
Luego le cambio los permisos a toda la carpeta y archivos por 505 (permisos
recurrentes).
Con estos permisos uno está imposibilitado de modificar las cadenas de
idioma desde dentro de la plataforma, pero creo que vale la pena el
"costo", si el beneficio es evitar la vulnerabilidad descrita.
De lo que dice Carlos, en el sentido de que su plataforma tiene 555, pues
una explicación del ataque pudo haber sido esto de 777 en el "locale" del
español internacional.
Saludos
PD
El archivo .htaccess que va dentro de "moodledata" lo tengo con 444.
Múy útiles ambos posts.
Sólo como sugerencia, en un hosting compartido me parece que es mejor tener
permisos 505 y/o 604, en lugar de 555 y 644 (como se mencionó más arriba).
Lo anterior, para impedir que otros integrantes del grupo de usuarios en el que
nos encontramos tengan acceso (así sea mínimo), a nuestra plataforma.
Por otra parte, yo mantengo el "config.php" ubicado en la raíz de Moodle,
con permisos 404.
Otra cuestión que es importante mencionar es que los archivos de idioma
distintos al inglés se almacenan en la carpeta "moodledata" (puede tener
otro nombre).
Como dicha carpeta debe tener permisos 777 (707 en un hosting compartido),
entonces los archivos de idioma adquieren esos permisos (eso recuerdo).
Como son archivos PHP, entonces según lo que he leído, hay una vulnerabilidad
por ahí, pues se le puede inyectar código malicioso a los archivos con toda
tranquilidad (se tiene máximo acceso y posibilidad de manipulación de los archivos).
En este sentido lo que yo acostumbro es colocar el idioma manualmente
(osea que no lo instala la plataforma, sino que yo lo descargo del sitio
de Moodle y luego lo subo por FTP, pues es lo que he visto que es mejor
en un hosting compartido por cuestiones de quién queda como propietario
de la carpeta).
Luego le cambio los permisos a toda la carpeta y archivos por 505 (permisos
recurrentes).
Con estos permisos uno está imposibilitado de modificar las cadenas de
idioma desde dentro de la plataforma, pero creo que vale la pena el
"costo", si el beneficio es evitar la vulnerabilidad descrita.
De lo que dice Carlos, en el sentido de que su plataforma tiene 555, pues
una explicación del ataque pudo haber sido esto de 777 en el "locale" del
español internacional.
Saludos
PD
El archivo .htaccess que va dentro de "moodledata" lo tengo con 444.
David y Pablo
Gracias por las recomendaciones, iré poniendo en práctica cada una de ellas e indico. Lo del idioma no lo había leído nunca, así que es un buen aporte, conjuntamente con lo demás.
Saludos y mil gracias nuevamente
Gracias por las recomendaciones, iré poniendo en práctica cada una de ellas e indico. Lo del idioma no lo había leído nunca, así que es un buen aporte, conjuntamente con lo demás.
Saludos y mil gracias nuevamente
Hola Carlos,
Como he dicho varias veces, para mí uno de los expertos más respetables
de Moodle es Iñaki (es una de las personas de quien más he aprendido
cosas sobre la plataforma y otros temas de tecnología).
Y pues de él es esta observación acerca del idioma.
Es cierto que está un tanto "oculta", pero aquí la dejo porque puede
resultar de utilidad (foros en inglés).
Y qué bueno haberla releído, pues los permisos indicados para el idioma son 404,
no 505 como había puesto antes equivocadamente.
Saludos
Como he dicho varias veces, para mí uno de los expertos más respetables
de Moodle es Iñaki (es una de las personas de quien más he aprendido
cosas sobre la plataforma y otros temas de tecnología).
Y pues de él es esta observación acerca del idioma.
Es cierto que está un tanto "oculta", pero aquí la dejo porque puede
resultar de utilidad (foros en inglés).
Y qué bueno haberla releído, pues los permisos indicados para el idioma son 404,
no 505 como había puesto antes equivocadamente.
Saludos
David
Gracias por la aclaración, pero ahora me encuentro con un grave problema y es que los estudiantes no pueden ingresar al sitio, y siempre les muestra el mensaje de Datos erróneos..
Sí tienen alguna idea de dónde puede estar el problema, le sugiero una ayuda, pues he revisado todas las configuraciones y no encuentro nada diferente.
Saludos
Gracias por la aclaración, pero ahora me encuentro con un grave problema y es que los estudiantes no pueden ingresar al sitio, y siempre les muestra el mensaje de Datos erróneos..
Sí tienen alguna idea de dónde puede estar el problema, le sugiero una ayuda, pues he revisado todas las configuraciones y no encuentro nada diferente.
Saludos
Hola Carlos,
Lo que voy a decir es "excesivamente empírico".
En algunas ocasiones hemos tenido problemas similares a lo que indicas.
La única manera en que se ha logrado ingresar al sitio es cambiar el idioma
de la plataforma.
Esto supone que el usuario puede ver el catálogo de idiomas en la
pantalla de "login".
De tal suerte que puede pasar, digamos, de español a inglés y luego regresar
a español.
Cuando haces esto y vuelves a poner tus datos de usuarios, puede entrar
a la plataforma.
No está de más que intentes esto (conviene que primero se vacíe el caché del
navegador).
Si no tienes activada la opción para mostrar dicho catálogo, puedes
habilitarlo a través de la base de datos, ubicando la tabla "mdl_config",
y colocando 1 (uno) en el renglón "langmenu".
Por otra parte considera que si tu plataforma fue intervenida por un
atacante, es muy difícil identificar el problema si no es revisando directamente
la base de datos, los scripts de la plataforma, etc.
Saludos
PD
La opción "menos empírica" que, supongo ya intentaste, es vaciar la carpeta
"sessions" de "moodledata" y/o verificar que tenga permisos 707.
Lo que voy a decir es "excesivamente empírico".
En algunas ocasiones hemos tenido problemas similares a lo que indicas.
La única manera en que se ha logrado ingresar al sitio es cambiar el idioma
de la plataforma.
Esto supone que el usuario puede ver el catálogo de idiomas en la
pantalla de "login".
De tal suerte que puede pasar, digamos, de español a inglés y luego regresar
a español.
Cuando haces esto y vuelves a poner tus datos de usuarios, puede entrar
a la plataforma.
No está de más que intentes esto (conviene que primero se vacíe el caché del
navegador).
Si no tienes activada la opción para mostrar dicho catálogo, puedes
habilitarlo a través de la base de datos, ubicando la tabla "mdl_config",
y colocando 1 (uno) en el renglón "langmenu".
Por otra parte considera que si tu plataforma fue intervenida por un
atacante, es muy difícil identificar el problema si no es revisando directamente
la base de datos, los scripts de la plataforma, etc.
Saludos
PD
La opción "menos empírica" que, supongo ya intentaste, es vaciar la carpeta
"sessions" de "moodledata" y/o verificar que tenga permisos 707.
David
Gracias por todas las informaciones que estas colocando en este tema, todas son útiles. Te comento que limpié la carpeta sessions y seguí los pasos del idioma tal como indicaste, todo se arregló, lo que no me fijé es sí fue consecuencia de ambos o uno solo de esos pasos, pues estaba presionado por los estudiantes, en especial los míos.
De todos modos seguiré revisando otras carpetas, es un trabajo de "hormiga", pero hay que hacerlo.
Muchas gracias por los aportes y sugerencias.
Gracias por todas las informaciones que estas colocando en este tema, todas son útiles. Te comento que limpié la carpeta sessions y seguí los pasos del idioma tal como indicaste, todo se arregló, lo que no me fijé es sí fue consecuencia de ambos o uno solo de esos pasos, pues estaba presionado por los estudiantes, en especial los míos.
De todos modos seguiré revisando otras carpetas, es un trabajo de "hormiga", pero hay que hacerlo.
Muchas gracias por los aportes y sugerencias.