Durante el trabajo diario, en ocasiones, debemos realizar tareas que nos gustaría documentar como es debido.
En esta entrada vamos a ver como guardar toda una sesión de terminal Linux, de tal forma que podamos incluirla a posteriori en cualquier documentación.
El comando que vamos utilizar es:
script
A modo de ampliación del post «Configuración firewall iptables Red Hat/CentOS 6, desde linea de comandos«, esta vez vamos a ver como asegurar las conexiones salientes de nuestro servidor.
El limitar las conexiones salientes puede parecer algo un tanto paranoico, pero en caso de un ataque tu máquina será utilizada para «saltar» a otras o enviar correos. Se que esto todavía puede sonar más paranoico todavía, pero son cosas que ocurren y son muy reales, quiero hacer un post más adelante tratando un caso real.
Vamos al lío, partimos de una situación inicial:
[root@oradb ~]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destinationVamos a configurar Apache (sobre un Ubuntu 12) para permitir el acceso de clientes que tengan un certificado SSL personal instalado, primero tenemos que crear algunas estructuras para poder más tarde trabajar con listas de revocación.
Lo primero es tener instalado openssl:
ubuntu@ip-10-112-31-82:~$ sudo aptitude install openssl
Crearemos una estructura de directorios que se ajuste a las rutas esperadas por el fichero de configuración openssl.cnf:
ubuntu@ip-10-112-31-82:~$ mkdir -p /vol/apache2_certs
ubuntu@ip-10-112-31-82:~$ cd /vol/apache2_certs/
ubuntu@ip-10-112-31-82:/vol/apache2_certs$ sudo cp /etc/ssl/openssl.cnf .El fichero openssl.cnf define una estructura de directorios para poder trabajar entre otras cosas con listas de denegación de certificados, vamos a editarlo y moficicar la linea:
Si añadimos discos en caliente (desde cualquier sistema de virtualización) es posible que el SO no se entera hasta que hagamos un rescan del bus scsi, esto se puede hacer con la herramienta:
rescan-scsi-bus.sh -aPara instalarla en RedHat/Centos:
yum install sg3_utilsLos volúmenes LVM tienen muchas ventajas pero cuando pinchamos un disco duro (con LVM) a un sistema operativo (mediante USB por ejemplo) y queremos acceder a los datos, vemos que no es algo automático.
Para acceder a los datos podemos montar directamente el volumen porque el device simplemente no existe, esto se puede solucionar fácilmente. La secuencia de acciones es:
1- Pinchar el HD (lógicamente)
2- Realizar un vgscan
3- Realizar un lvscan
4- Activar el volumen LVM deseado
5- Montar el device y acceder a los datos
Para extraer el HD hay que:
En esta ocasión vamos a ver como regenerar un RAID por software en Linux.
Se ha detectado un error de tipo SMART mediante:
Diagnostico smarctl:
[root@simba ~]# smartctl -H /dev/sda
smartctl 5.42 2011-10-20 r3458 [x86_64-linux-2.6.32-279.el6.x86_64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
Failed Attributes:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 001 001 051 Pre-fail Always FAILING_NOW 330223La autenticación más básica que podemos configurar en un Apache es el acceso mediante fichero, pero en esta entrada vamos a ver como configurar Apache para que autentique los usuarios contra un LDAP.
Las ventajas son evidentes, podemos usar un directorio centralizado de autenticación LDAP, ya sea para validarnos en aplicaciones o para acceder a los servicios web de la empresa.
Para los ejemplos se ha usado un Ubuntu 12.04, lo primero que tenemos que hacer es instalar los módulos de Apache necesarios y activarlos:
sudo aptitude install libapache2-mod-ldap-userdir
sudo a2enmod authnz_ldapRecientemente se ha puesto en contacto conmigo un compañero de fatigas llamado Miguel Angel (un saludo), a ver si le podía echar una mano con unos ataques que está teniendo. Evidentemente no usaré sus datos para nada en esta entrada.
En esta estrada vamos realizar un filtrado más preciso de las comunicaciones entrantes, para evitar ataques DOS.
En el anterior post «Impedir ataques denegación de servicio (DOS Denial Of Service) en Linux (Match extension limit)», se mostraba como realizar un filtrado limitando el número de accesos. La gran mejora de la extensión recent vs limit, es que recent mantiene una lista de IPs de origen de comunicación y los límites son establecidos por IP de origen. La extensión limit impone límites independientemente del origen, es un límite global.
Cuando ponemos un servidor web funcionando, hay que tener aplicar una protección básica para evitar cualquier posibilidad de que alguna «buena» persona (con todo el sarcasmo), se dedique a poner algún que otro JMeter (excelente software pensado para pruebas de cargar) con la idea de saturar nuestro servidor.
Esto son cosas que realmente ocurren, no es nada paranoico .
Una forma de evitar estos ataques es mediante iptables (tengo otra entrada más amplia sobre iptables), un ejemplo de configuración sería: