Con la finalidad de limitar el acceso al WHM de tal forma que sólo pueda ser realizado desde direcciones IP predeterminadas, o en su defecto, en el caso de que alguien trate de ingresar en el WHM desde una IP no predefinida como aceptada, se le hagan cuatro preguntas para solo dejarle acceder cuando las conteste todas correctamente (más allá del hecho de que la persona tenga el usuario y la contraseña correctos), a continuación explicamos los pasos a seguir:
Ingresar a:
WHM > Security Center > Security Questions
Hacer clic en el botón:
“Edit questions and answers”
Seleccionar las cuatro preguntas y colocar sus respuestas respectivas, luego clic en el botón “Save“. Algunos ejemplos de las preguntas disponibles en la herramienta son:
What is your father’s middle name?
What was the name of your first boyfriend or girlfriend?
In what city did you honeymoon? (Enter full name of city only)
What is the first name of the best man/maid of honor at your wedding?
Ahora deben colocarse las IPs de acceso a WHM en la lista blanca, para ello se debe hacer clic en el botón:
“Add or remove recognized IP addresses“
Se deben ingresar las IPs una a una (Ver más adelante como ingresar lotes de IP vía SSH).
Luego, para que esto quede habilitado se debe ingresar en:
WHM > Security Center > Configure Security Policies
Marcar las casillas de:
Limit logins to verified IP Addresses
Password Strength
Colocar la Fortaleza del Password en 75% y Guardar.
Para agregar un lote de direcciones IP para el acceso root del WHM, se debe ingresar por SSH y editar:
Vale decir que si agregamos manualmente una IP a través de los pasos anteriores la podremos ver en dicho archivo. A su vez, para conocer la lista de IPs que se deben agregar para la sede de la empresa deben solicitarlas a la gerencia.
Para el caso de los Resellers, después de haber habilitado las Políticas de Seguridad anteriroes, cuando ingresen al WHM la primera vez el sistema les permitirá agregar las cuatro preguntas con sus respuestas correspondientes. A su vez, cada vez que entren al WHM desde una nueva IP, luego de contestar correctamente las preguntas se agregará la IP a la lista blanca en forma automática.
Para el caso de los resellers de la empresa, si queremos agregar el lote de IPs, luego de haber ingresado al menos una vez al WHM por el reseller y habiendo creado las preguntas y respuestas como se indica en el párrafo anterior, podemos editar el archivo directamente con:
Linux Malware Detect (LMD) es un escáner de malware para Linux liberado bajo la licencia GNU GPLv2, que está diseñado en torno a las amenazas que enfrentan en común los entornos hospedados. Este utiliza los datos de las amenazas de los sistemas de red de detección de intrusos para extraer el malware que está siendo utilizado activamente en los ataques y genera firmas para la detección. Adicionalmente, los datos de las amenazas también se derivan de envíos de los usuarios con la característica de Comprobación LMD y desde recursos de la comunidad malware. Las firmas que utiliza LMD son hashes MD5 de archivos y los coincidencias de parones hexadecimales, también se pueden exportar fácilmente a cualquier número de herramientas de detección, tales como ClamAV.
El panorama de amenazas en entornos de hospedaje compartido es distinto del manejado por las suites estándar de detección de virus, ya que dichos productos son principalmente para la detección de troyanos a nivel del sistema operativo, rootkits y virus que infectan archivos tradicionales, pero fallan en la detección de la variedad cada vez mayor de programas maliciosos a nivel de las cuentas de los usuarios que sirven como una plataforma de ataque.
Características:
Detección de hash MD5 de archivos para la detección rápida e identificación de amenazas
Análisis de patrones de base hexadecimal para la identificación de variantes de las amenazas
Componente de análisis estadístico para la detección de amenazas ofuscado (por ejemplo: base64)
Detección integrada del ClamAV para usarlo como motor de escáner para mejorar el rendimiento
Actualización de firma integrada con la función -u |-update
Actualización de versión integrada con la función -d |-update-ver
Opción de Escanear Recientes para analizar sólo los archivos que se han añadido / cambiado en X días
Opción de Escanear Todo para el análisis basado en la ruta completa
Opción de Verificación para cargar el malware sospechoso hacia rfxn.com para su revisión / hashing
Sistema de información completo para ver los resultados del análisis actual y el anterior
Cola de cuarentena que almacena las amenazas de una forma segura, sin los permisos
Opción de cuarentena por lotes para poner en cuarentena los resultados de un análisis actual o pasado
Opción de Restauración de Cuarentena para restaurar los archivos a la ruta original, con su propietario y permisos correspondientes
Opción de Suspención de Cuenta en Cuarentena para la suspender o revocar del Shell a usuarios del cPanel
Reglas de Limpieza para intentar la eliminación de cadenas de inyección de malware
Opción de Limpieza por Lotes para intentar la limpieza por informes de análisis previos
Reglas de Limpieza para eliminar malware que utiliza base64 y gzinflate (malware inyectado por base64)
Cron diario basado en la exploración de todos los cambios en las últimas 24 horas en los directorios Home de los usuarios
Script del cron diario compatible con los sistemas HR, Cpanel y Ensim
Rastreo de archivos en tiempo real basado en “Kernel inotify” para los archivos creados / modificados / movidos
Monitor del Kernel inotify que puede tomar la ruta de datos del STDIN o ARCHIVO
Monitor del Kernel inotify con característica conveniente para controlar a los usuarios del sistema
Monitor del Kernel inotify puede ser restringido a una raíz html configurable por el usuario
Monitor del Kernel inotify con límites dinámicos sysctl para un rendimiento óptimo
Alerta de Kernel inotify a través de informes diarios y/o semanales opcionalmente
E-mail de información después de la ejecución de análisis (manual y todos los días)
Opciones para ignorar ubicaciones (patch), extensiones y la firmas
Opción de escáner en segundo plano para las operaciones de exploración sin supervisión
Registro detallado y salida de todas las acciones
Fuente de datos:
La diferencia clave con LMD es que no sólo sirve para la detección de malware basados en firmas / hashes que alguien genera sino que se trata de un proyecto global que activamente hace seguimiento de las amenazas y genera firmas basadas en dichas amenazas del mundo real que están circulando actualmente.
Hay cuatro fuentes principales de datos de malware que se utiliza para generar firmas LMD:
IPS de la Red Eje: La red dispone de más de 35.000 sitios web, y como tal recibe una gran cantidad de abusos diarios, que se registran en la red EDGE del creador de LMD (rfxn.com). Los eventos IPS se procesan para extraer los url del malware, decodificar cargas POST y los datos abusivos codificados en base64/gzip y, finalmente, que el malware sea recuperado, examinado, clasificado y generadas las firmas en cada caso. La gran mayoría de las firmas LMD se han derivado de datos que se extrajeron de IPS.
Datos de la Comunidad: Los datos son agregados desde múltiples sitios web de comunidades de malware, tales como clean-mx y malwaredomainlist luego se procesan para obtener nuevo malware su revisión, clasificación y luego generar las firmas.
ClamAV: Las firmas de detección de hexadecimal y MD5 de ClamAV se monitorean para conocer las actualizaciones relevantes que se aplican al grupo de usuarios objetivo de LMD y se añaden al proyecto, según proceda. Hasta la fecha se han obtenido cerca de 400 firmas desde ClamAV mientras que el proyecto LMD ha contribuido hacia ClamAV con la presentación de más de 1.100 firmas y lo sigue haciendo en forma permanente.
Envío de usuario: LMD tiene una función de emisión de verificaciones que permite a los usuarios enviar programas maliciosos sospechosos para su revisión, se ha convertido en una característica muy popular y genera una media de unos 30 a 50 envíos semanales. Actualizaciones de firmas:
Las firmas de LMD se actualizan por lo general una vez al día o con mayor frecuencia en función de los datos de las amenazas entrantes de la función de comprobación LMD, la extracción de IPS malware y otras fuentes. La actualización de las firmas en las instalaciones de LMD se realiza diariamente a través de la ejecución del script cron.daily con la opción -update, que además se puede ejecutar manualmente en cualquier momento.
Vale decir que está disponible un canal RSS para el seguimiento de las actualizaciones de amenazas de malware: http://www.rfxn.com/api/lmd
Amenazas detectadas:
LMD 1.4.0 detecta a la fecha un total de 7.241 (5.393 MD5 / 1848 HEX) firmas, de las cuales las más comunes detectadas son:
La característica de monitoreo inotify está diseñada para controlar las ubicaciones / usuarios en tiempo real por las operaciones de crear / modificar / cambiar archivos. Esta opción requiere un núcleo que soporte inotify_watch (CONFIG_INOTIFY) que se encuentra en los núcleos 2.6.13 y 5 + CentOS / RHEL por defecto.
Hay tres modos para ejecutar el monitor y se refieren a lo que será objeto del seguimiento, que son: USUARIOS | RUTAS | ARCHIVO.
Ejemplo: maldet — monitor users
Ejemplo: maldet — monitor /root /monitor_paths
Ejemplo: maldet — monitor /home/juan, /home/jose
Las opciones se desglosan como sigue:
USUARIOS: La opción users tomará los directorios home de todos los usuarios del sistema que están por encima de lo configurado para inotify_minuid y los monitoreará. Si se ha configurado inotify_webdir entonces solo se monotorearán los directorios web de los usuarios, si es que existen.
RUTAS: Una lista de rutas separadas por comas a ser monitoreadas
ARCHIVO: Archivo con una lista de archivos separados por líneas a ser monitoreados
Una vez que comience maldet en modo monitor, se preprocesarán las rutas basadas en la opción especificada seguido por el inicio del proceso de inotify. La puesta en marcha del proceso de inotify puede ser una tarea que consuma mucho tiempo, ya que necesita configurar un gancho de monitoreo para todos los archivos en las rutas a controlar. Aunque el proceso de inicio puede afectar la carga de forma temporal, una vez iniciado el proceso este mantendrá todos los sus recursos dentro de la memoria del kernel y el espacio de usuario tendrá una huella muy pequeña en la memoria o uso de la CPU.
Instalación
Ingresar por SSH y ejecutar:
cd /usr/local/src wget http://www.rfxn.com/downloads/maldetect-current.tar.gz tar -xvzf maldetect-current.tar.gz cd maldetect-* ./install.sh
Esto instalará el LMD y mostrará algo como
Linux Malware Detect v1.4.2-1 (C) 2002-2011, R-fx Networks <proj@r-fx.org> (C) 2013, Ryan MacDonald <ryan@r-fx.org> inotifywait (C) 2007, Rohan McGovern <rohan@mcgovern.id.au> This program may be freely redistributed under the terms of the GNU GPL installation completed to /usr/local/maldetect config file: /usr/local/maldetect/conf.maldet exec file: /usr/local/maldetect/maldet exec link: /usr/local/sbin/maldet exec link: /usr/local/sbin/lmd cron.daily: /etc/cron.daily/maldet maldet(5073): {sigup} performing signature update check... maldet(5073): {sigup} local signature set is version 2010122710638 maldet(5073): {sigup} latest signature set already installed
Para configurarlo se debe ejecutar:
nano /usr/local/maldetect/conf.maldet
Buscar las siguientes variables y colocar los valores indicados:
email_alert=1 email_subj="Alerta de Analisis de Malware en $(hostname)" email_addr="hostmaster@sudominio.com"
Para eliminar Falsos Positivos (Ignorar):
Hay cuatro archivos para ignorar los falsos positivos y se descomponen de la siguiente manera:
1. Excluir Rutas:
/usr/local/maldetect/ignore_paths
En este archivo se colocan en cada línea las rutas que se van a excluir de los resultados de búsqueda
Ejemplo:
/home/usuario/public_html/cgi-bin
2. Excluir Extensiones de Archivos:
/usr/local/maldetect/ignore_file_ext
En este archivo se colocan en cada línea las extensiones que se van a excluir de los resultados de búsqueda
Ejemplo:
.js .css
3. Excluir Firmas:
/usr/local/maldetect/ignore_sigs
En este archivo se colocan en cada línea las firmas que se van a excluir de los resultados de búsqueda
Ejemplo:
base64.inject.unclassed
4. Excluir Rutas Regexp:
/usr/local/maldetect/ignore_inotify
En este archivo se colocan en cada línea las rutas regexp que se van a excluir del monitoreo inotify
Ejemplo:
^/home/user$ ^/var/tmp/#sql_.*\.MYD$
Línea de Comandos:
Una vez LMD está instalado se puede ejecutar a través del comando ‘maldet’, la opción ‘– help’
ofrece un resumen detallado de las opciones de uso:
-u, –update
Actualiza las firmas de detección de malware desde rfxn.com
-m, –monitor USUARIOS|RUTAS|ARCHIVO
Ejecuta maldet con el monitoreo del kernel inotify al crear / modificar archivos
Si se han especificado USUARIOS (users), monitorea los directorios home para usuarios con UID > 500
Si se especifica un ARCHIVO, las rutas serán extraídas del archivo correspondiente
Si las rutas se especifican, deben estar separadas por comas, sin comodines!
Ej: maldet –monitor users
Ej: maldet –monitor /root/monitor_paths
Ej: maldet –monitor /home/mike,/home/ashton
-k, –kill
Cancelar el servicio de monitoreo inotify
-r, –scan-recent RUTA DIAS
Explorar los archivos creados / modificados en los últimos X DIAS (por defecto: 7d, comodín:?)
Ej: maldet -r /home/?/public_html 2
-a, –scan-all RUTA
Analizar todos los archivos en la RUTA (por defecto: /home, comodín:?)
Ej: maldet -a /home/?/public_html
-c, –checkout ARCHIVO
Cargar el malware sospechoso hacia rfxn.com para su revisión y hashing en firmas
-l, –log
Ver los eventos del archivo de registros de maldet
-e, –report SCANID email
Ver el informe de análisis de exploración más reciente o de un SCANID específico y, opcionalmente, enviar por e-mail el informe suministrando una dirección de correo electrónico
Ej: maldet –report
Ej: maldet –report list
Ej: maldet –report 050910-1534.21135
Ej: maldet –report SCANID usuario@dominio.com
-s, –restore FILE|SCANID
Restaurar el archivo de la cola de cuarentena a la ruta original o restaurar todos los elementos de un SCANID específico
Con la finalidad de asegurarnos de mantener respaldos de los espacios de las cuentas del cPanel en Servidores externos al menor costo posible y en forma segura, podemos registrar una cuenta Premium en el servicio Fileserve.com. Este punto explica como realizar estos backups externos, sin embargo, le indicamos que Fileserve prohibe usar sus espacios para backups automáticos por lo que su cuenta podría ser eliminada sin derecho a reclamos. Mantenemos este punto en el curso porque explica los respaldos en servicios de almacenamiento remoto, para fines educativos.
Lo primero que hay que hacer es contratar una cuenta premium en www.fileserve.com.
Una vez creada la cuenta debemos ingresar por SSH en el servidor y ubicarnos en el directorio donde se encuentran los respaldos locales de las cuentas y ejecutar:
cd /backup/cpbackup/weekly/ nano respaldos.sh
Ahora debemos colocar en el archivo lo siguiente:
#!/bin/sh # Respalda los archivos de backup en la cuenta de Fileserve if (("`date +%w`" != "6")); then exit else cd /backup/cpbackup/weekly/ fecha=$(date +'%m.%d.%Y_%H-%M-%S_') > remotos.ftp echo user USUARIO CLAVE >> remotos.ftp echo mkdir ServerN >> remotos.ftp echo cd ServerN for i in `ls *.tar.gz` do ln -s $i "backup-$fecha$i" >>remotos.ftp echo put "backup-$fecha$i" done >>remotos.ftp echo quit ftp -n ftp.fileserve.com < remotos.ftp echo > remotos.ftp rm -f remotos.ftp rm -f backup* echo "Respaldos Externos realizados para el Servidor N" fi # Fin
Guardarlo y Salir del editor.
NOTA: Deben hacerse varios cambios en función del servidor correspondiente, como son:
Sustituir arriba el USUARIO y la CLAVE por los provistos por Fileserve Sustituir la letra N en el Servidor N por el número que corresponda. En función del día que se quiera ejecutar se debe colocar en el if el número correspondiente ” ejemplo: 0=Dom, 1=Lun, 2=Mar “¦ 6=Sab). Sustituir la N en ServerN por el número que corresponda según el servidor de producción a respaldar de tal forma que los archivos sean guardados en la carpeta correspondiente. Ahora debemos ejecutar:
chmod 700 respaldos.sh Luego debemos crear el cron que ejecutará los respaldos remotos mensualmente, para ello ejecutamos:
crontab -e
Insertamos al final:
0 7 1-7 * 6 /backup/cpbackup/weekly/respaldos.sh
Guardamos y salimos.
En el caso anterior, el cron se ejecutará los primeros 7 días de cada mes y todos los sábados a las 7:00am, sin embargo, como lo que se quiere es que el script corra 1 vez al mes, por ejemplo solo el primer sábado del mes, es importante el condicional que se le colocó al script al inicio donde solo permite su ejecución si el día coincide con el deseado (ej. Sábado).
Es importante destacar que el cron lo debemos ejecutar un día diferente al día en que se hacen los backups programados del cpanel para evitar sobrecargas innecesarias.
A su vez, no debemos colocar la ejecución de los cron iguales en todos los servidores de producción ya que Fileserve causará una cola innecesaria. Lo mejor es colocarlos en horarios diferentes entre los servidores de producción (ej. Sáb 7am, Sáb 2pm, Sáb 7pm, Dom 7am, etc.).
Para finalizar reiniciamos el servicio crond y listo:
service crond restart
Todo lo anterior es para el caso de los servidores de producción. Ahora bien, para los servidores de desarrollo el script debe ubicarse en:
cd /respaldos/ nano respaldos.sh
Ahora debemos colocar en el archivo lo siguiente:
#!/bin/sh # Respalda los archivos de backup en la cuenta de Fileserve if (("`date +%w`" != "3")); then exit else cd /mnt/software/respaldos/ fecha=$(date +'%m.%d.%Y_%H-%M-%S_') > /respaldos/remotos.ftp echo user USUARIO CONTRASEÑA >> /respaldos/remotos.ftp echo mkdir Desarrollo >> /respaldos/remotos.ftp echo cd Desarrollo for i in `ls *.tar.gz` do ln -s $i "backup-$fecha$i" >>/respaldos/remotos.ftp echo put "backup-$fecha$i" done >>/respaldos/remotos.ftp echo quit ftp -n ftp.fileserve.com < /respaldos/remotos.ftp echo > /respaldos/remotos.ftp rm -f /respaldos/remotos.ftp rm -f backup* echo "Respaldos Externos realizados para el Servidor Desarrollo" cd /mnt/software/respaldos/db/ > /respaldos/remotos.ftp echo user USUARIO CONTRASEÑA >> /respaldos/remotos.ftp echo mkdir Desarrollo >> /respaldos/remotos.ftp echo cd Desarrollo for i in `ls *.sql` do tar -czf "$i.tar.gz" $i done for i in `ls *.tar.gz` do ln -s $i "backupdb-$fecha$i" >>/respaldos/remotos.ftp echo put "backupdb-$fecha$i" done >>/respaldos/remotos.ftp echo quit ftp -n ftp.fileserve.com < /respaldos/remotos.ftp echo > /respaldos/remotos.ftp rm -f /respaldos/remotos.ftp rm -f backup* rm -f *.tar.gz echo "Respaldos Externos de BD realizados para el Servidor de Desarrollo" fi # Fin
Guardarlo y Salir del editor.
NOTA: Deben hacerse varios cambios en función del servidor correspondiente. El ejemplo anterior es para Dataserver. Los cambios a tomar en cuenta son:
Sustituir arriba el USUARIO y la CLAVE por los provistos por Fileserve
Sustituir el Servidor Dataserver por el nombre que corresponda, tanto para el echo como para la carpeta donde se guardarán los archivos (ej. Desarrollo1, Desarrollo2, etc.).
En función del día que se quiera ejecutar se debe colocar en el if el número correspondiente ” ejemplo: 0=Dom, 1=Lun, 2=Mar “¦ 6=Sab).
La carpeta de los respaldos en Dataserver es /mnt/software/respaldos/ sin embargo en los servidores de Desarrollo es /backup/. En ambos casos la carpeta que contiene la base de datos se denomina db y esta dentro de la carpeta del respaldo correspondiente. Ahora debemos ejecutar:
chmod 700 respaldos.sh
Luego debemos crear el cron que ejecutará los respaldos remotos mensualmente, para ello ejecutamos:
crontab -e
Insertamos al final:
0 19 1-7 * 3 /respaldos/ respaldos.sh
Guardamos y salimos.
En el caso anterior, el cron se ejecutará los primeros 7 días de cada mes y todos los Miércoles a las 7:00pm, sin embargo, como lo que se quiere es que el script corra 1 vez al mes, por ejemplo solo el primer Lunes del mes, es importante el condicional que se le colocó al script al inicio donde solo permite su ejecución si el día coincide con el deseado (ej. Miércoles).
A su vez, no debemos colocar la ejecución de los cron iguales en todos los servidores de desarrollo ya que Fileserve causará una cola innecesaria. Lo mejor es colocarlos en horarios diferentes entre los servidores de Desarrollo (ej. Lunes 7pm, Martes 7pm, Miércoles 7pm, etc.). Debe ser en días laborables y de noche para que no congestionen la conexión lenta que nos proveen localmente.
Para finalizar reiniciamos el servicio crond y listo:
Debemos crear el cron que se ejecute los Sábados a las 5:30am y nos envíe el email con la lista de archivos PHP existentes en carpetas con permisos 777, para ello debemos ejecutar:
crontab -e
Colocar al final del archivo el siguiente contenido:
service crond restart (ó con /etc/rc.d/init.d/crond restart)
LISTO.
NOTA: Si el editor que maneja el crontab es el editor “vi” entonces debemos ir al final del archivo, presionar la tecla ” i ” para pasar al modo de inserción, pegar el contenido en una nueva línea, luego presionar la tecla ESC para salir del modo de inserción y finalmente ejecutar el comando para guardar y salir con ” :wq “.
Finalmente, si repetidamente un cliente tiene archivos php en carpetas 777 y queremos cambiar los permisos de las carpetas a 755 el comando SSH a ejecutar es:
cd /usr/local/src wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl chmod 755 mysqltuner.pl ./mysqltuner.pl
Esperar unos segundos (puede tomar un rato en función del servidor) y mostrará los resultados recomendados para cambiar el archivo de configuración my.cnf.
Para monitorear los procesos de MYSQL se recomiendan los siguientes comandos:
mysqladmin proc
También existen dos aplicaciones útiles:
http://mtop.sourceforge.net
http://innotop.sourceforge.net
Sin embargo, usaremos mysqladmin para lo que nos interesa.
Otras herramientas de diagnóstico útiles para sistemas con cargas altas de mysql, siempre que se haya ejecutado mysql por lo menos desde hace 2 días, son:
Mysqlidxchk:
Esta herramienta verifica las tablas de mysql para identificar índices no utilizados que puedan causar lentitud o ineficiencia en el mysql. Básicamente revisa los logs para identificar los índices innecesarios.
Para instalarla los comandos son:
cd /usr/local/src wget hackmysql.com/scripts/mysqlidxchk-1.1 chmod 755 mysqlidxchk* mv mysqlidxchk* mysqlidxchk
Para ejecutarlo (dependiendo si es el log general o el de queries lentos):
Esta herramienta verifica los logs general y slow de mysql para identificar los usuarios que hacen mayor porcentaje de uso de las bases de datos que puedan causar lentitud o sobrecargas en mysql.
Para instalarla los comandos son:
cd /usr/local/src wget hackmysql.com/scripts/mysqlsla chmod 755 mysqlsla* mv mysqlsla* mysqlsla
Para ejecutarlo (dependiendo si es el log general o el de queries lentos):
El sistema LFD va llenando el archivo de IPs bloqueadas del CSF constantemente por lo que el mantenimiento del mismo se puede volver muy engorroso. Para que este archivo se limpie cada 4 horas (específicamente al minuto 50 cada 4 horas) debemos ejecutar:
cd /etc/csf nano limpiaips.sh
Colocar en el archivo el siguiente contenido:
#MAILTO=hostmaster@sudomimiocom #!/bin/sh #Limpiar las IP Bloqueadas en el CSF cada 4 horas echo > /etc/csf/csf.deny /etc/csf/csf.pl -r
Guardar el archivo y salir del editor.
Ahora debemos darle permisos de ejecución con:
chmod 700 limpiarips.sh
Luego debemos crear el cron que se ejecute en el minuto 50 cada 4 horas, para ello debemos ejecutar:
crontab -e
Colocar al final del archivo el siguiente contenido:
service crond restart (ó con /etc/rc.d/init.d/crond restart)
LISTO.
NOTAS:
Si el editor que maneja el crontab es el editor “vi” entonces debemos ir al final del archivo, presionar la tecla ” i ” para pasar al modo de inserción, pegar el contenido en una nueva línea, luego presionar la tecla ESC para salir del modo de inserción y finalmente ejecutar el comando para guardar y salir con ” :wq “.
Algunos detalles del formato del archivo de Denegación de Ips son:
Permite el format CIDR (e.j. 192.168.254.0/24)
Si se agrega el texto “do not delete” a los comentarios de una Ip registrada entonces la misma no se borrará cuando se llegue al límite DENY_IP_LIMIT
Permite el filtrado avanzado de puertos e ips con el siguiente formato:
Cuando las aplicaciones en PHP graban archivos en el servidor, el usuario predeterinado para dichos archivos es “nobody”. Esto afecta el cálculo del espacio usado en el servidor ya que el mismo se basa en el usuario:grupo.
Para resolver esto debemos ejecutar un cron que deberá ejecutarse a las 5:00 AM todos los días, para que ubique todos los archivos creados por nobody y los cambie al usuario:grupo del usuario correspondiente, para ello ejecutamos:
crontab -e
Y al final colocamos:
0 5 * * * for i in `ls /home/`; do find /home/$i/ -user nobody -exec chown $i:$i "{}" \;; done > /dev/null 2>&1
Guardamos el archivo (recordar cambiar XX por lo que corresponda según el servidor)
