Buscando en Google la frase "Hosting Chile" notaremos que estamos entrando a un mercado complejo. La página de resultados está llena de información por todas partes.
En la parte superior, tres o incluso cuatro resultados pagados de Hosting. Uno de ellos en inglés, otro una página falsa para promocionar a una empresa y el tercero el clásico hosting malo que paga por aparecer allí.
A la derecha, ocho empresas de hosting que pagan por aparecer y lograr clientes. Y en último lugar vemos los resultados naturales.
Hoy en día las empresas de hosting en Chile han crecido en número en forma desmedida. ¿Volverán los antiguos tiempos donde teníamos no más de seis empresas en nuestro país?
¿Qué traerá el futuro? Muchas irán desapareciendo y muchas más se irán creando.
¡Suerte en su elección!
viernes, 11 de mayo de 2012
martes, 4 de octubre de 2011
Como instalar KVM en CentOS 6
Esta es una guia práctica para instalar KVM en CenOS 6.
Vamos a asumir que al instalar CentOS se eligió la opción "instalación mínima"
Debemos tomar en cuenta que todas las herramientas de virtualización se encuentran en los siguientes grupos:
Si vamos a utilizar un entorno gráfico, entonces debemos instalar las fuentes para visualizar correctamente la aplicacion virt-manager:
A continuación verificamos si el moduulo KVM se ha cargado:
Debiera aparecer en el resultado kvm-intel o kvm-intel de acuerdo a la CPU utilizada por el servidor.
Ahora debemos reiniciar el servidor.
Como queremos que cada máquina virtual sea directamente accesible desde afuera y no solamente desde el servidor, entonces debemos crear un puente de red.
Para esto, debemos tener instalado en nuestro servidor el paquete bridge-utils. Entonces debemos verificar que se encuentr instaldo:
Si obtenemos respuesta quiere decir que el paquete está correctamente instalado. De no ser así debemos instalarlo con el siguiente comando:
Antes de crear el puente, si tenemos definida un IP estática, el contenido del archivo /etc/sysconfig/network-scripts/ifcfg-eth0 debe verse similar a:
Por seguridad vamos a realizar una copia de seguridad del archivo:
En seguida crearemos nuestro archivo con el puente a partir dela configuracion de nuestra tarjeta de red:
Debemos modificar ambos archivos, y deben quedar similar al siguiente ejemplo:
Felicitaciones, el puente de red ya está configurado. Debemos revisar que la configuracion es corecta. En caso de haber cualquier error podríamos perder la conexión con el servidor a través de la interfaz eth0.
Para reiniciar el servicio de red:
Finalmente podemos revisar nuestra configuración con el siguiente comando:
Vamos a asumir que al instalar CentOS se eligió la opción "instalación mínima"
Debemos tomar en cuenta que todas las herramientas de virtualización se encuentran en los siguientes grupos:
- Vritualization
- Virtualization client
- Virtualization Platform
- Virtualization Tools
# yum groupinstall "Virtualization*"Si vamos a utilizar un entorno gráfico, entonces debemos instalar las fuentes para visualizar correctamente la aplicacion virt-manager:
# yum install dejavu-lgc-sans-fontsA continuación verificamos si el moduulo KVM se ha cargado:
# lsmod | grep kvmDebiera aparecer en el resultado kvm-intel o kvm-intel de acuerdo a la CPU utilizada por el servidor.
Ahora debemos reiniciar el servidor.
Creando un puente de red
Como queremos que cada máquina virtual sea directamente accesible desde afuera y no solamente desde el servidor, entonces debemos crear un puente de red.
Para esto, debemos tener instalado en nuestro servidor el paquete bridge-utils. Entonces debemos verificar que se encuentr instaldo:
# rpm -q bridge-utilsSi obtenemos respuesta quiere decir que el paquete está correctamente instalado. De no ser así debemos instalarlo con el siguiente comando:
# yum install bridge-utilsAntes de crear el puente, si tenemos definida un IP estática, el contenido del archivo /etc/sysconfig/network-scripts/ifcfg-eth0 debe verse similar a:
DEVICE=eth0
BOOTPROTO=static
HWADDR=00:14:5E:C2:1E:40
IPADDR=10.10.1.152
NETMASK=255.255.255.0
ONBOOT=yes Por seguridad vamos a realizar una copia de seguridad del archivo:
# cp /etc/sysconfig/network-scripts/ifcfg-eth0 /root/ifcfg-eth0En seguida crearemos nuestro archivo con el puente a partir dela configuracion de nuestra tarjeta de red:
# cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-br0 Debemos modificar ambos archivos, y deben quedar similar al siguiente ejemplo:
ifcfg-eth0 ifcfg-br0 DEVICE=eth0
TYPE=Ethernet
HWADDR=00:14:5E:C2:1E:40
ONBOOT=yes
NM_CONTROLLED=no
BRIDGE=br0
DEVICE=br0
TYPE=Bridge
NM_CONTROLLED=no
BOOTPROTO=static
IPADDR=10.10.1.152
NETMASK=255.255.255.0
ONBOOT=yes
Felicitaciones, el puente de red ya está configurado. Debemos revisar que la configuracion es corecta. En caso de haber cualquier error podríamos perder la conexión con el servidor a través de la interfaz eth0.
Para reiniciar el servicio de red:
# /etc/init.d/network restartFinalmente podemos revisar nuestra configuración con el siguiente comando:
# ifconfig
jueves, 29 de septiembre de 2011
Rutas importantes de cPanel y apache
En este post vamos a revisar algunas rutas de archivos importantes de cPanel:
Apache
Archivos de configuracion: /usr/local/apache/conf
Archivo de configuracion apache: /usr/local/apache/conf/httpd.conf
Logs de Apache: /usr/local/apache/logs
Archivos web del servidor: /usr/local/apache/htdocs
Nota: los archivos web del servidor son accesibles directamente desde la dirección IP o desde el nombre del servidor.
Apache
Archivos de configuracion: /usr/local/apache/conf
Archivo de configuracion apache: /usr/local/apache/conf/httpd.conf
Logs de Apache: /usr/local/apache/logs
Archivos web del servidor: /usr/local/apache/htdocs
Nota: los archivos web del servidor son accesibles directamente desde la dirección IP o desde el nombre del servidor.
lunes, 29 de agosto de 2011
Como evitar que los usuarios deshabiliten mod_security
Sabemos que mod_security es una gran forma de proteger nuestros servidores.
Sin embargo, en mod_security 1.x los usuarios podían deshabilitarlo en el archivo .htaccess. Existen algunos exploits que aprovechan esa vulnerabilidad en seguridad, como por ejemplo syrian shell.
No obstante, mod_security 2.x ya no es posible deshabilitarla desde archivos .htacess.
La recomendación es utilizar la versión 2.x lo antes posible.
Sin embargo, en mod_security 1.x los usuarios podían deshabilitarlo en el archivo .htaccess. Existen algunos exploits que aprovechan esa vulnerabilidad en seguridad, como por ejemplo syrian shell.
No obstante, mod_security 2.x ya no es posible deshabilitarla desde archivos .htacess.
La recomendación es utilizar la versión 2.x lo antes posible.
viernes, 19 de agosto de 2011
Como prevenir que los usuarios modifiquen php.ini
Cuando usamos suPHP es posible que nuestros usuarios creen un archivo php.ini en la misma carpeta que su script, lo que les permite sobreescribir cualquier directiva de seguridad que tengamos.
Para terminar con este problema debemos editar el archivo configuracion de suphp:
Y lo modificaremos de la siguiente forma:
Luego reiniciamos apache y asunto arreglado.
Para terminar con este problema debemos editar el archivo configuracion de suphp:
# nano /opt/suphp/etc/suphp.confY lo modificaremos de la siguiente forma:
[phprc_paths]
;Uncommenting these will force all requests to that handler to use the php.ini
;in the specified directory regardless of suPHP_ConfigPath settings.
application/x-httpd-php=/usr/local/lib/
application/x-httpd-php4=/usr/local/lib/
application/x-httpd-php5=/usr/local/lib/
Luego reiniciamos apache y asunto arreglado.
martes, 16 de agosto de 2011
Como limpiar una cuenta hackeada
Como administradores a veces nos enfrentamos a que alguna de nuestras cuentas han sido hackeadas.
Primero que todo debemos restaurar los archivos originales en caso de que haya tratado de un defacement. En un defacement, el delincuente modifica el archivo index del sitio para poner algún tipo de mensaje de su interés.
Después que restablecimos la apariencia del sitio web dañado debemos buscar los scripts que el atacante habrá dejado en la cuenta con la finalidad de repetir una y otra vez su hazaña.
Para eso utilizaremos el comando:
Con el primer comando nos moveremos a la raíz de la cuenta atacada. Debemos reemplazar cuenta_atacada por el username real de la cuenta que fue atacada.
El segundo comando nos muestra una lista de todos los archivos que fueron modificados durante las últimas 24 horas. Si nuestra cuenta fue hackeada antes de un día, debemos cambiar el -1 por un -2 para dos días, -3 para tres días, y así sucesivamente.
Identificados los scripts procedemos a eliminarlos o a clasificarlos según sean las políticas de nuestra administración.
Luego debemos revisar las bases de datos para ver si nuestro atacante se creó una cuenta de usuario administrador, cosa típica para sitios con Joomla! u OsCommerce y eliminarla.
Podemos dejarlo hasta aquí, pero todavía debemos determinar cómo fue vulnerada la cuenta para poder tomar las medidas necesarias de modo de evitar que se vuelva a repetir en el futuro.
Primero que todo debemos restaurar los archivos originales en caso de que haya tratado de un defacement. En un defacement, el delincuente modifica el archivo index del sitio para poner algún tipo de mensaje de su interés.
Después que restablecimos la apariencia del sitio web dañado debemos buscar los scripts que el atacante habrá dejado en la cuenta con la finalidad de repetir una y otra vez su hazaña.
Para eso utilizaremos el comando:
cd /home/cuenta_atacada/public_html
find . -mtime -1Con el primer comando nos moveremos a la raíz de la cuenta atacada. Debemos reemplazar cuenta_atacada por el username real de la cuenta que fue atacada.
El segundo comando nos muestra una lista de todos los archivos que fueron modificados durante las últimas 24 horas. Si nuestra cuenta fue hackeada antes de un día, debemos cambiar el -1 por un -2 para dos días, -3 para tres días, y así sucesivamente.
Identificados los scripts procedemos a eliminarlos o a clasificarlos según sean las políticas de nuestra administración.
Luego debemos revisar las bases de datos para ver si nuestro atacante se creó una cuenta de usuario administrador, cosa típica para sitios con Joomla! u OsCommerce y eliminarla.
Podemos dejarlo hasta aquí, pero todavía debemos determinar cómo fue vulnerada la cuenta para poder tomar las medidas necesarias de modo de evitar que se vuelva a repetir en el futuro.
Could not fetch uid or gid for root
Es posible que alguna vez que intentamos entral al panel WHM nos encontremos con el siguiente mensaje:
Internal Server Error
Could not fetch uid or gid for : root
Por suerte la causa de este problema es muy sencilla y su solución también lo es:
Lo que pasa es que estamos tratando de ingresar como usuario root al cPanel, cuando debemos ingresar al WHM.
Probablemente estamos ingresando a:
http://www.midominio.com/cpanel
Cuando debemos ingresar a:
http://www.midominio.com/whm
Internal Server Error
Could not fetch uid or gid for : root
Por suerte la causa de este problema es muy sencilla y su solución también lo es:
Lo que pasa es que estamos tratando de ingresar como usuario root al cPanel, cuando debemos ingresar al WHM.
Probablemente estamos ingresando a:
http://www.midominio.com/cpanel
Cuando debemos ingresar a:
http://www.midominio.com/whm
Suscribirse a:
Entradas (Atom)