Editamos el fichero principal de configuracion de GDM3: /etc/gdm3/daemon.conf
En la seccion [daemon] veremos esto:
[daemon]
# AutomaticLoginEnable = false
# AutomaticLogin =
lo cambiamos por:
[daemon]
AutomaticLoginEnable = true
AutomaticLogin = mijack
Al reiniciar, nuestro sistema se loguear automaticamente con el usuario MiJacK.
Ale 
<?php
if (!$_POST)
{
?>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.js"></script>
<script src="http://ajax.aspnetcdn.com/ajax/jquery.validate/1.9/jquery.validate.js" type="text/javascript"></script>
<script type="text/JavaScript">
$(document).ready(function() {
$('#formu').validate({
rules: {
name: {required: true},
email: {required: true},
subject: {required: true}
},
messages: {
name: {required: "Introduzca su nombre"},
email: {required: "Introduzca su email"},
subject: {required: "Introduzca el asunto del mensaje"}
}
});
});
</script>
<title></title>
</head>
<body>
<div id='errores'>
</div>
<form id='formu' method='post'>
<label for='name'></label>Nombre:</label> <input type='text' name='name' id='name' class='required'><br>
<label>email:</label> <input type='text' name='email' id='email' class='required'><br>
<label>subject:</label> <input type='text' name='subject' id='subject' class='required'><br>
<input type='hidden' name='enviado' value='true'>
<input type='submit' value='prueba' name='enviado' id='enviado' class='required'>
</form>
</body>
</html>
<?php
}
else
{
echo "Recibido<br>";
print_r($_POST);
}
?>
Tras mi experiencia de 5 años como sysadmin Linux, he aprendido qué cosas evitar a la hora de tener un servidor Debian relativamente seguro.
Casi todas estos consejos parten de la paranoia y algunos simplemente se rigen por el sentido común, pero merece la pena listarlos y revisarlos de vez en cuando.
Allá vamos:
- Utilizar siempre que sea posible conexiones cifradas cuando vamos a trabajar con datos sensibles:
Protocolos como SSH, SCP y https fijan transmisiones de datos cifradas.
Con ello evitamos ademas de que nos snifen el tráfico, pudiendo acceder a datos sensibles y contraseñas, ataques tipo man in the middle.
- Password robustos y encriptados:
Utilizar siempre password robustos. “Churros” de mínimo ocho caracteres, con al menos un caracter en mayúsculas, uno en minúsculas y uno numérico.
Ejemplo: Ax84jMn4
Es de sentido común que el password de root de nuestro sistema no sea ’12345′.
- Mantener el servidor actualizado.
Debian especialmente y en general las distribuciones derivadas suelen tener un exhaustivo control de actualizaciones y reparaciones de bugs. Para ello, tenemos que tener entre nuestros repositorios, los repositorios oficiales de seguridad
Actualizar un sistema debian es tan facil como teclear:
apt-get update
apt-get upgrade
- Cuidado con el software de origen dudoso .
Vigilar qué tenemos en nuestro fichero sources.list. Intentar utilizar solo repositorios oficiales.
- Desinstalar o deshabilitar servicios innecesarios
Para ello podemos hacer uso del comando chkconfig (originario de distribuciones basadas en rpm, existe también para debian)
La idea es parar y deshabilitar el arranque de servicios que no vamos a necesitar.
- FIREWALL
Intentar filtrar todas las conexiones entrantes mediante un firewall, denegando el acceso a servicios cuya conexión desde el exterior no es necesaria. Si no disponemos de un firewall, más abajo hablo de IPTABLES.
- No instalar el entorno gráfico y mucho menos, ejecutarlo como root:
No tiene sentido tener las X en un servidor en producción. Si tenerlo arrancado de por sí ya es un agujero de seguridad y una fuente de inestabilidad del sistema, no hablemos de arrancarlo con el usuario root.
- Separación de particiones
Separar las particiones siempre es una buena idea. Tanto en lo que a seguridad se refiere, como a la hora de evitar que el disco se llene.
Lo ideal suele ser separar en particiones diferentes los directorios /var/, /home/, /usr/, /boot y /tmp.
- Fijar como Noexec las particiones que no vayan a necesitarlo, sobre todo /tmp
Una vez separadas las particiones, lo ideal es fijar (al menos) el directorio /tmp como noexec.
De esta forma, ante una posible intrusión, no se pueden ejecutar binarios desde /tmp, cosa bastante habitual cuando se intenta ejecutar código malicioso en un servidor.
- Revisar con frecuencia logs y gráficas de rendimiento.
Especialmente las gráficas de cpu y tráfico nos pueden ayudar a localizar comportamientos inapropiados, como un incremento de ancho de banda o de uso de cpu, que pudiera deberse a código malicioso, envíos de emails, shells, etc.
- cuidado con el comando Sudo, que lo carga el diablo:
Si puede ser, que no esté habilitado más que para lo estrictamente necesario.
Una entrada de este tipo en el fichero sudoers:
usuarioxx ALL=(ALL) ALL
puede suponer dar privilegios de root automaticamente al usuario que consiga el password de un usuario regular.
- Shell por defecto de usuarios que no necesiten loguearse:
Si existe un usuario en el sistema con el que vamos a ejecutar algún tipo de proceso, o que van a ser necesarios para conexiones via FTP, pero no van a necesitar loguearse en linea de comandos, podemos fijar su shell por defecto como /bin/false.
El usuario seguirá existiendo, podrá ser propietario de ficheros/directorios, podrá ingresar via FTP, pero jamás ejecutar una shell.
Para ello, editamos el fichero /etc/password, y en la linea donde están definidas las opciones de usuario, al final, definimos su shell como /bin/false:
usuarioFtp:x:3000:3000:,,,:/home/usuarioFtp:/bin/false
Permisos:
- chmod 777 está prohibido:
Nunca nunca nunca, hacer cambios de permiso a lo loco. hacer un chmod 777 sobre un fichero o un directorio está prohibido. Y más aun si se hace para solucionar algún problema de permisos que no sabemos como atajar.
Recomendaciones concretas en diferentes tipos de servicios:
SSh
- prohibir loguearse como root :
en el fichero de configuración (/etc/ssh/sshd_config), podemos deshabilitar la opción PermitRootLogin, fijandola en No:
PermitRootLogin no
De esta forma siempre tendremos que loguearnos como un usuario regular y escalar a root.
- Permitir el acceso sólo a los usuarios indicados
Al igual que para deshabilitar el login con el usuario root, podemos indicar qué usuarios podrán conectarse con la siguiente directiva en /etc/ssh/sshd_config:
AllowUsers mijack operador
De esta forma, permitimos solo al usuario mijack y al usuario operador ingresar en el sistema. Si hubiera más usuarios no podrían acceder via ssh.
Apache:
Uso de mod_secure:
- Para evitar inyecciones de código en nuestros sitios web, podemos activar el módulo mod_secure, que dispone de unas directivas por defecto muy completas que bloquearan URLS sospechosas. En ocasiones es demasiado restrictivo.
proteger con htpasswd
- Todo directorio o ruta sensible a ingresos de usuario no deseados o con contenido sensible, puede ser protegido mediante htpasswd. De esta forma al intentar acceder a una url concreta, nos pedirá user y password.
MySQL:
- Fijar siempre un password de root:
De no fijar un password de root para MySQL (por defecto vacio en muchas distribuciones de linux), cualquier usuario regular podrá loguearse en el sistema tecleando:
$ mysql -u root
- Cada bases de datos con su usuario y password:
Si existen varias bases de datos en nuestro sistema, es recomendable que cada una tenga un usuario y password de acceso. De forma que el usuario de una base de datos no pueda escribir en todas.
- Evitar conexiones externas.
Por defecto MySQL no admite conexiones externas puesto que solo escucha las peticiones desde localhost. Es preferible no cambiar esa configuración si no es necesario cien por cien.
Modo ultraparanoia:
- iptables:
iptables (antiguamente ipchains) es un framework inlcuido en el nucleo de linux que permite filtrar los paquetes de red, denegando o aceptando trafico dependiendo de multiples factores.
Si tenemos un nivel majo de paranoia, podemos configurar iptables para rechazar todo el tráfico que no se adapte al puramente necesario.
El funcionamiento de iptables es complejo puesto que también se puede usar para el enrutado de tráfico y nateo de puertos.
Ejemplo:
Rechazamos todo el tráfico por el puerto 22, y luego establecemos que solo aceptaremos el de una ip en concreto, xxx.xxx.xxx.xxx:
iptables -t filter -I INPUT -p tcp –dport 22 -j DROP
iptables -t filter -I INPUT -p tcp -s xxx.xxx.xxx.xxx –dport 22 -j ACCEPT
- SELinux (del inglés Security-Enhanced Linux, Seguridad Mejorada de Linux):
Creado a imagen y semejanza del control de acceso utilizado por el departamento de defensa de los Estados Unidos, SELinux implementa unas políticas de seguridad y controles de acceso extremadamente flexibles, con la posibilidad de ser a su vez, extemadamente paranoicas.
Algunas distribuciones, como CentOS, lo traen activado por defecto.
SELinux Permite el control total de usuarios, procesos archivos y sockets, de forma que según lo restrictivos que seamos al configurarlo, podemos impedir la ejecucion de servicios o binarios, el login de usuarios que no estén en la lista de permitidos o incluso la escritura en determinados directorios.
Seguiremos añadiendo cosas
Saludos.
MiJacK.
AWStats es una herramienta open source de análisis de tráfico web. Saca los datos de los logs de apache y a partir de esos datos genera los informes.
Awstats puede ser un complemento perfecto a otras herramientas como Google Analytics. Además de las visitas, podremos consultar el tráfico real generado, tamaño de ficheros, tráfico por MIME Type, etc.
Vamos a instalar awstats en un servidor debian que ya tiene un apache funcionando desde hace algún tiempo y vamos a sacar las gráficas del dominio albumdata.com
Comenzamos instalando el paquete awstats
apt-get install awstats
Nos genera una configuración standard en /etc/awstats. Vamos a hacer una copia del fichero y a personalizarlo para nuestro dominio
cd /etc/awstats
cp awstats.conf awstats.albumdata.com.conf
Editamos el fichero awstats.albumdata.com.conf y modificamos solamente estos tres valores:
El fichero de log de apache para el sitio que queremos analizar
LogFile="/var/log/apache2/albumdata_access.log"
SiteDomain="albumdata.com"
HostAliases="www.albumdata.com"
Por último vamos a configurar el acceso en el virtualhost que queramos. Yo añado al sitio por defecto (el que muestro cuando hago una peticion por ip http://xx.xx.xx.xx)
editamos /etc/apache2/sites-enabled/000-default
y añadimos:
Alias /awstats-icon/ /usr/share/awstats/icon/
ScriptAlias /awstats/ /usr/lib/cgi-bin/
De esta forma, si llamamos al sitio http://xx.xx.xx.xx/awstats/awstats.pl?config=albumdata.com , veremos las gráficas.
La primera vez que visitemos el sitio las gráficas estarán vacias puesto que aun no hemos recopilado los datos de los logs.
El funcionamiento de awstats se basa en la ejecucion del comando /usr/lib/cgi-bin/awstats.pl, indicandole el dominio que del que queremos extraer las gráficas.
Para ello, lo más práctico es fijar un cron con la frecuencia que deseemos (en mi caso cada hora).
La primera ejecucion la haremos a mano:
# /usr/lib/cgi-bin/awstats.pl -config=albumdata.com -update
Create/Update database for config "/etc/awstats/awstats.albumdata.com.conf" by AWStats version 6.95 (build 1.943)
From data in log file "/var/log/apache2/albumdata_access.log"...
Phase 1 : First bypass old records, searching new record...
Direct access to last remembered record has fallen on another record.
So searching new records from beginning of log file...
Phase 2 : Now process new records (Flush history on disk after 20000 hosts)...
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Jumped lines in file: 0
Parsed lines in file: 98320
Found 0 dropped records,
Found 16 corrupted records,
Found 0 old records,
Found 98304 new qualified records.
En el fichero del virtualhost de apache donde vayamos a colocar el acceso a awstats (en mi caso 000-default), justo debajo de las lineas que pusimos antes, ponemos estas
<Directory /usr/lib/cgi-bin/>
AuthName "Acceso restringido a Estadísticas"
AuthType basic
AuthUserFile /etc/awstats/.htpasswd
require valid-user
</Directory>
htpasswd -c /etc/awstats/.htpasswd user
Reiniciamos apache, y ahora al acceder a las graficas nos pedira un user y password, que se correspondera con el que acabamos de crear.
Hecho todo esto, obtenemos unas estadísticas muy completas, algo parecido a esto.
Saludos.
MiJacK
En ocasiones nos sera util redirigir la salida de la consola de MySQL para poder procesarla de una forma concreta, por ejemplo, pasandosela al comando head o tail para ver solo las últimas o primeras lineas o a un more o less para poder ver la salida mas comodamente.
para ello existe el comando pager:
mysql>pager more
PAGER set to 'more'o
mysql>pager tail
PAGER set to 'tail' y para volver a la salida estandar por defecto:
mysql> nopager
PAGER set to stdout Con el único fin de agrupar máquinas y servicios para tener una visibilidad más clara desde el interfaz web, podemos definir unos grupos de hosts y servicios.
Para ello, vamos a crear un fichero nuevo al que llamaremos gruops.cfg, y lo incluiremos en el fichero principal de configuracion:
Añadimos la última linea:
# Ficheros de configuracion
cfg_file=/usr/local/nagios/etc/objects/commands.cfg
cfg_file=/usr/local/nagios/etc/objects/contacts.cfg
cfg_file=/usr/local/nagios/etc/objects/timeperiods.cfg
cfg_file=/usr/local/nagios/etc/objects/templates.cfg
<span style="color: #ff0000;"> cfg_file=/usr/local/nagios/etc/objects/groups.cfg</span>
y creamos el fichero groups.cfg con este contenido:
define hostgroup{
hostgroup_name servidoresLinux
alias Servidores Linux
members servidor, servidor2
}
define servicegroup{
servicegroup_name chequeos http
alias Servicios http
members servidor,HTTP, servidor2,HTTP
}
de esta forma, creamos unos grupos de hosts y servicios que podremos gestionar desde el interfaz web.
Vamos a añadir el chequeo de dos servicios sencillos asociados a nuestro host “servidor”, que añadimos en el capítulo anterior.
Editamos el fichero servidor.cfg y añadimos:
define service{
use generic-service
host_name servidor
service_description HTTP
check_command check_http
}
Esto establece un chequeo http, ligado a servidor, heredando las opciones de la plantilla generic-service.
Vamos a pasarle al check_command algún parametro extra. Para ello, vamos a fijarnos en la definición del comando en commands.cfg:
# 'check_http' command definition
define command{
command_name check_http
command_line $USER1$/check_http -I $HOSTADDRESS$ $ARG1$
}
Vemos que al lamar al comamdo, se le envía los datos de la máquina usando la macro $HOSTADDRESS$, y un parametro extra llamado $ARG1$.
Si ejecutamos el comando desde la linea de comandos, veremos que arguemntos podemos pasarle:
# /usr/local/nagios/libexec/check_http
Usage:
check_http -H <vhost> | -I <IP-address> [-u <uri>] [-p <port>]
[-w <warn time>] [-c <critical time>] [-t <timeout>] [-L] [-a auth]
[-b proxy_auth] [-f <ok|warning|critcal|follow|sticky|stickyport>]
[-e <expect>] [-s string] [-l] [-r <regex> | -R <case-insensitive regex>]
[-P string] [-m <min_pg_size>:<max_pg_size>] [-4|-6] [-N] [-M <age>]
[-A string] [-k string] [-S] [--sni] [-C <age>] [-T <content-type>]
[-j method]
En este caso, nos interesa hacer el chequeo http, pero al puerto 8083, que es donde tendremos escuchando nuestro servidor web.
# /usr/local/nagios/libexec/check_http -p 8083 xxx.xxx.xxx.xxx
HTTP OK: HTTP/1.1 200 OK - 453 bytes in 0,015 second response time |time=0,014957s;;;0,000000 size=453B;;;0
Para adaptar esta llamada al chequeo de nuestro servicio, editamos servidor.cfg y fijamos el chequeo así:
check_command check_http!-p 8083
de esta forma, llama al binario definido en el comando check_http, pasandole además como $ARG1$, ‘-p 8083′.
El comando set nos permite establecer o visualizar el contenido de las variables de shell.
si tecleamos ‘set -o’ veremos la lista de dichas variables y su valor:
[root@xxxx]# set -o
allexport off
braceexpand on
emacs on
errexit off
errtrace off
functrace off
hashall on
histexpand on
history on
ignoreeof off
interactive-comments on
keyword off
monitor on
noclobber off
noexec off
noglob off
nolog off
notify off
nounset off
onecmd off
physical off
pipefail off
posix off
privileged off
verbose off
vi off
xtrace off
Hay dos variables qeu nos van a ayudar a hacer un buen debug de nuestros shell scripts: noexec y xtrace.
Si activamos la variable noexec, podremos ejecutar un script sin que se ejecute ningún comando que contenga, aunque sí seguirá las estructuras de control (if, while, for.. ). Este comando no funciona en modo interactivo, es decir, solo lo podemos ejecutar dentro de un script:
Aqui tenemos un ejemplo. Todo lo que esté por debajo de ‘set -n’ no lo va a ejecutar, aunque sí que sigue el flujo hasta el final del script. Sólamente nos ayuda a chequear la sintaxis. Si hubiera un error en el if, lo veríamos por pantalla.
echo "Entramos en el script"
set -n
fichero="/tmp/fich.txt"
if [ -f $fichero ]
then
echo "El fichero existe, mostramos su contenido";
cat $fichero;
else
echo "El fichero no existe, lo creamos";
date > $fichero;
fi
al ejecutarlo vemos esto:
[root@xxx]# sh pruebaset.sh
Entramos en el script
Si cometieramos el error de, en lugar de escribir ‘if’, escribir ‘i’:
i [ -f $fichero ]
Veriamos esto:
[root@xxxx ]# sh pruebaset.sh
Entramos en el script
pruebaset.sh: line 5: syntax error near unexpected token `then'
pruebaset.sh: line 5: `then'
La otra variable molona es xtrace. Si activamos dicha variable, por cada comando o estructura de control, veremos una traza de lo que hace. Nos ayudará a debuguear el script en caso de errores con variables, etc.
ej:
set -x
echo "Entramos en el script"
fichero="/tmp/fich.txt"
if [ -f $fichero ]
then
echo "El fichero existe, mostramos su contenido";
cat $fichero;
else
echo "El fichero no existe, lo creamos";
date > $fichero;
fi
En una primera ejecución veríamos esto:
[root@xxx]# sh pruebaset.sh
+ echo 'Entramos en el script'
Entramos en el script
+ fichero=/tmp/fich.txt
+ '[' -f /tmp/fich.txt ']'
+ echo 'El fichero no existe, lo creamos'
El fichero no existe, lo creamos
+ date
Y en una segunda:
[root@xxx]# sh pruebaset.sh
+ echo 'Entramos en el script'
Entramos en el script
+ fichero=/tmp/fich.txt
+ '[' -f /tmp/fich.txt ']'
+ echo 'El fichero existe, mostramos su contenido'
El fichero existe, mostramos su contenido
+ cat /tmp/fich.txt
Fri Sep 30 11:02:06 CEST 2011
Una de las cosas bonicas de xtrace es que también se puede activar en modo interactivo para debuguear errores en comandos.
Un saludo.
MiJacK.
Vamos a poner en marcha un ejemplo real y vamos a ver todos los ficheros de configuración y entidades que participan en el proceso.
Queremos que nagios comprube la disponibilidad de la máquina con ip 192.168.183.1 al que denominaremos ‘servidor’. Comprobaremos la disponibilidad de dicha maquina mediante ping.
Se estableceran chequeos cada 5 minutos. Si la maquina estuviera down, volvería a chequear a cada 2 minutos.
Al 3º intento, se envíaria un mail a los operadores.
Al recuperarse la máquina, los operadores también recibirán un email confirmando la recuperación.
creamos el fichero servidor.cfg en el directorio hosts con el siguiente contenido:
define host{
use linux-server
host_name servidor
alias Servidor principal
address 192.168.183.1
}
comprobamos la configuración de Nagios:
/usr/local/nagios/bin/nagios -v /etc/nagios/nagios.cfg
Veremos esto:
[...]
Warning: Host ‘servidor’ has no services associated with it!
[...]
Total Warnings: 1
Total Errors: 0
Simplemente veremos un warning que nos indica que el Host servidor no tiene servicios asociados. Más tarde lo solucionaremos.
Reiniciamos Nagios para que los cambios tengan efecto
/etc/init.d/nagios restart
En la alta de este host ha tomado parte la siguiente entidad:
linux-server (plantilla).
Si editamos el fichero templates.cfg, podremos ver que se define en esa plantilla:
define host{
name linux-server
use generic-host
check_period 24x7
check_interval 5
retry_interval 1
max_check_attempts 10
check_command check-host-alive
notification_period workhours notification_interval 120
notification_options d,u,r
contact_groups admins
register 0
}
Vemos que la plantilla linux-server, hereda a su vez la configuración de la plantilla generic-host. La plantilla generic host, define una serie de opciones principales, entre otras, el periodo de notificacion 24×7.
Además, en la plantilla linux-server, definimos el periodo de chequeo 24×7, un intervalo de 5 minutos entre chequeos, intervalo de 1 minuto tras un fallo, un máximo de 10 intentos, tras el que se envíara una alerta, el comando de chequeo, el periodo de notificación, intervalo, opciones, y contactos. Por último, register 0 indica que esta definición no ha de registrarse en el sistema como un elemento, por lo que sólo formará parte de las plantillas.
Todos estos elementos, están definidos en diferentes ficheros de configuración, tal como vimos en los capítulos anteriores.
En el interfaz web de nagios, si vamos a la seccion hosts, veremos el nuevo host creado:
Instalación y configuración de Nagios Sobre Debian 6
Según Wikipedia, Nagios es:
Nagios es un sistema de monitorización de redes de código abierto ampliamente utilizado, que vigila los equipos (hardware) y servicios (software) que se especifiquen, alertando cuando el comportamiento de los mismos no sea el deseado. Entre sus características principales figuran la monitorización de servicios de red (SMTP, POP3, HTTP, SNMP…), la monitorización de los recursos de sistemas hardware (carga del procesador, uso de los discos, memoria, estado de los puertos…), independencia de sistemas operativos, posibilidad de monitorización remota mediante túneles SSL cifrados o SSH, y la posibilidad de programar plugins específicos para nuevos sistemas.
Tengo más de un año de experiencia administrando Nagios: Instalación, labor de investigación y mantenimiento, que incluye la creación de script para chequear diferentes tipos de servicios, bocas de switch, procesos lanzados en un servidor, etc.
Dicho sistema chequeaba servicios en una granja de unos 200 servidores, avisando en caso de fallo vía email o SMS al técnico de guardia para proceder a solucionar el error.
Voy a intentar dejar aquí a forma de nota, instrucciones básicas de configuración de Nagios.
El funcionamiento de nagios puede resultar un poco enrevesado y la curva de aprendizaje un poco dura al principio es por ello que es importante comprender su funcionamiento interno.
Hay diferentes entidades relacionadas con la configuración de Nagios. Aunque mi documentación se basa en ficheros, voy a proceder a explicar las diferentes entidades que forman aprte de la misma. Realmente toda la configuración podría estar en un sólo fichero de configuración, pero para hacerla más amigable se despieza la misma en diferentes ficheros y se usan includes para enlazar todos los ficheros en el fichero principal, nagios.cfg.
command: Define un comando de chequeo o de notificación. A esos comandos nos referimos cuando establecemos la configuracion de un nuevo chequeo.
contact: Define un contacto al que le llegará una notificación en caso de cambio de estado de uno de los chequeos.
contactgroup: Sirve para agrupar los contactos de forma que sea más sencillo gestionarlos.
host: Definimos un host, indicando su ip, nombre, etc. Podemos chequear la disponibilidad de ese host o asignarle servicios.
service: Definimos un servicio para chequear. Dicho servicio siempre irá asignado a un host.
template: Define las plantillas que mas tarde heredarán las entidades. Sirve para facilitar la configuración.
timeperiod: Define un periodo de tiempo personalizado, tanto para chequeos como para alertas.
Comentarios recientes