Mini Guia buenas practicas GNU/Linux Parte III

2.2 Acceso Remoto.
2.2.1 SSH.
SSH (Secure SHell) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red.SSH trabaja de forma similar a como se hace con telnet. La diferencia principal es que SSH usa técnicas de cifrado que hacen que la información que viaja por el medio de comunicación vaya de manera no legible y ninguna tercera persona pueda descubrir el usuario y contraseña de la conexión ni lo que se escribe durante toda la sesión; aunque es posible atacar este tipo de sistemas por medio de ataques de REPLAY y manipular así la información entre destinos.
SSH se instala por defecto en multitud de distribuciones, y no pocos SysAdmin pasan por alto la configuración de SSH por el mero hecho de que las conexiones se cifran.Error grave.En distribuciones GNU/Linux, dedicando unos 5 minutos,podremos blindar nuestros accesos vía SSH.La opción más recomendable es no usar SSH ni ningún acceso remoto, pero como debemos acceder a la máquina, la mejor opción es utilizar llaves RSA.Como este documento es una simple introducción, en http://www.securityfocus.com/infocus/1806 podeis encontrar más información sobre este tema, y de paso, suscribirse a las listas de correo, que son bastante interesantes. En el fichero sshd_config, limitaremos el acceso a usuarios,passwords..etc.
Desde hace un tiempo, para blindar los accesos por SSH a las máquinas que administro, suelo instalar fail2ban(http://www.fail2ban.org). Fail2ban básicamente actúa en modo "watchdog" o "perro guardían" sobre una serie de servicios configurados, y mediante reglas de condición-acción bloquea los accesos a dichos servicios implementando reglas de Iptables.Muy recomendado.

2.2.2 Sesiones X remotas.
(Completar)
2.2.3 Webmin y otros.
Webmin es una opción cómoda y segura(https) para administrar máquinas Linux-Unix.No obstante, recomiendo encarecidamente limitar el acceso a Webmin, creando usuarios con permisos limitados exclusivamente a los servicios a administrar, así como establecer limitaciones de acceso a las máquinas o redes desde las que se permitirá el acceso. Esto es posible desde el propio Webmin, pero nunca está de más que nuestro amigo Iptables también lo haga.

Por suerte existen multitud de herramientas web para la administración de servicios en máquinas GNU/Linux, pero muchas de ellas supeditan la usuabilidad y sencillez de la interfaz a la seguridad.Como ejemplo tenemos PHPLDAPADMIN, que sí, es una herramienta excepcional, pero...no creeis que no cifrar conexiones que manejan datos relativos a los usuarios del sistema(LDAP) es, como mínimo, un riesgo evitable? Ustedes mismos.

2.2.4 Iptables.
Fundamental, como la boina. Suspenso al SysAdmin que no implemente iptables en su máquina. 4.950.000 páginas relativas a iptables nos podemos encontrar en google.com. No soy la persona más indicada para hablar de iptables, pero paginas como www.pello.info o www.netfilter.org nos pueden ayudar a dar los primeros pasos.
2.2.5 Logs.
Al igual que iptables, y la boina,punto fundamental.Examinar exhaustivamente los logs del sistema nos permitirá prevenir fallos en la máquina,pero también localizar intentos de ataque a nuestros servicios.

Ludusparty.net 2007

Mal.Muy mal.Después de 1 hora y 10 minutos de viaje, tardamos 1 hora más en llegar al Palacio de Congresos, y después 30 minutos en que nos ubicaran.En definitiva, una basura.
Lo malo.

• Indicaciones: Malas o nulas. Mal indicado en la web, y en Lugo, casi nadie sabía del evento, y por si fuese poco, no sabían dónde se celebraba.Ni con GPS dimos llegado.
• Des-Organización: Al llegar al recinto; que por cierto es cojonudo para este tipo de eventos, nos vamos a recepción y nos colocan a mi a y Pableras uno en el norte y otro en... Una de las personas de la organización, nos dice que si no somos de un clan,tenemos que colocarnos donde nos digan. Al final, nos van a ubicar y ya hay gente en nuestros sitios...Por cierto,en lugar de alquilar o comprar trajes de ninja para los de la organización, se hubiesen preocupado un poco más por este aspecto.En fin...muy mal.
• Conexión a Internet.Mal. No nos pudimos conectar ni 1 minuto durante las 12 horas que estuvimos en la party.No sé el presupuesto de la party, pero por los 20€ de la entrada, que me parece un robo a mano armada, no disponer de conexión a Internet.Lamentable
  
• Indicaciones: No estaba indicado ni los servicios, ni el lugar habilitado para dormir...En fin, un desastre.Vino gente de Palencia, si si , de Palencia y no sabían ni dónde dormir.Mal, mu mal.
  
• Servicio de recogida de basura. Unos pesados. De 3:00 hasta las 6:00 tenías a un tipo dándote la chapa por si querías tirar algo a la basura.Joder! soy mayor de edad y no me gusta estar rodeado de mierda,si la almaceno, cuando termine de comer o beber, tiro el envase. A mi en el fondo, como el tipo estaba trabajando pues mira...un respeto, pero teníais que ver la cara de algunos gamers, que estaban viciando a COD4 o Counter Strike, cuando el tipo les tocaba el hombro para recoger la basura.Mal ,muy mal.

Lo mejor.

• Maquinas recreativas: Sin lugar a dudas cojonudo. Llegar al recinto y poder jugar al Street Fighter II en recreativa a un módico precio de 0€ euros, es cojonudo.

En fin ,que como no mejore el tema, veo jodido que asista el proximo año. Saludos desde A Coruña.

Mini Guia buenas practicas GNU/Linux Parte II

Queridisimos hippies, vamos con la segunda entrega(Alpha, sin revisar, con dos cojones!) de la "Mini Guia buenas practicas GNU/Linux" Parte II.
2.- Breves notas sobre seguridad.

2.1 Acceso Fisico.Es obvio que por mucho empeño que pongamos en "fortificar" nuestra maquina ante ataques externos y posibles intrusos, la seguridad fisica suele ser un punto que pocos SysAdmin tienen en cuenta.Entre las inumerables recomendaciones hago incapie en:
2.1.1 Acceso a Rack. Control de accesos a la maquina/maquinas en cuestion.Tener un control sobre el numero de llaves,tarjetas de acceso y titulares de las mismas,garantiza el NO ANONIMATO y depuracion de responsabilidades en caso de desastre.La utilizacion de camaras IP o videovigilancia nos alertara del uso indebido de HD Externos o Pendrives.Hoy en dia una solucion de camara IP es muy asequible, pudiendo adquirir modelos con relacion calidad-precio mas que aceptable por menos de 200 euros.La conexion a una central de alarmas en caso de "opertura dil cremallero" nos es descabellada.
En caso de que la ubicacion del rack de comunicaciones sea distinta a la del rack de servidores,aplicamos lo dicho en el parrafo anterior.[Ampliar]
2.1.2 Bloqueo Acceso BIOS y Secuencia Arranque.Nunca, bajo ningun concepto se debe facilitar el acceso a la BIOS de una maquina en produccion, y mucho menos poder arrancar desde un Pendrive USB o CD/DVD-ROM.
2.1.3 Sistema Alimentacion Ininterrumpida.Un SAI nos protege ante un corte de suministro o mal funcionamiento de la red electrica.Consideraremos la adquisicion de un SAI como parte fundamental en la estabilidad de nuestros sistemas.
2.1.4.Factores externos.Existen numerosos factores externos que pueden influir directamente en el correcto desempeño de los servicios de nuestras maquinas; entre ellos podemos destacar las inundaciones,incendios..etc.Contar con un buen sistema de aire acondicionado,detectores de humo...es esencial para prevenir desastres.

En realidad la segunda entrega es la mitad del punto 2, en el que doy unas pinceladas acerca de las restricciones del acceso físico a las maquinas, amen de otras cosillas.

Mini Guia buenas practicas GNU/Linux

Espero compredais esto es una version Alpha aun sin revision.

Mini Guia buenas practicas instalacion servidor de correo GNU/Linux


S.O: DEBIAN GNU/LINUX 4.0 ETCH
KERNEL: 2.6.22 o superior, elimando modulos no necesarios, tales como: PCMCIA,Wireless..etc.
PAQUETES:
- Actualizar el Sistema: apt-get dist-upgrade
- Compilacion kernel: wget http://www.mandcspain.com/paquetekernel
- Sistema: postfix,spamassassin,dovecot-common,dovecot-imapd,spamassassin,spamc,mailx,apache,procmail


1.-Configuraciones y comprobaciones previas.


1.1.- Especial cuidado si vamos a enviar emails directamente desde el servidor.Es necesario saber si el ISP permite activar SPF sobre los registros MX del DNS.En caso afirmativo,activar SPF para que apunte a la IP fija del gateway que sera configurado como puerta de enlace predeterminada.

1.2.- Comprobar que la IP no esta en listas de SPAM.Evidentemente esto es una tarea tediosa,dificil y complicada.Muchos SysAdmin deciden abandonar este punto y seguir con los siguientes(si es que siguen algun patron!!!!), ya no lo consideran importante o simplemente lo ignoran.Mal hecho.Las URL que utilizaremos en un principio son las siguientes.Ni mucho menos son las unicas, pero pueden ayudarnos:

http://www.rbl.jp/ckdb/
http://www.moensted.dk/spam/
http://spamlinks.net/filter-dnsbl-lookup.htm#general-sites

1.3 La Documentacion es imprescindible.
1.3.1 Documentacion cuentas.Utilizaremos fetchmail(www.catb.org/~esr/fetchmail/) para que "recoja" los correos desde el servidor POP3 y, mediante procmail(www.procmail.org) los entrege al servidor IMAP dovecot(www.dovecot.org).En instalaciones donde el numero de usuarios supera la veintena(aunque no lo supere debemos hacerlo),se recomienda utilizar un Shell Script que automatice todo este proceso.[Pendiente Linkar Script]
1.3.2 Cuotas de disco.La correcta definicion de cuotas de disco ayudara al SysAdmin a prevenir desastres del tipo "Ups,el server se ha quedado sin espacio en disco" o "Mira un cosa, abro el Autoluk(Outlook) y me dice asdklajsdlkjasdljkasdlkajsdlkajsd".Webmin(www.webmin.com)facilita mucho esta tarea.
1.3.3 Password.Habilitaremos la caducidad de las contraseñas, dependiendo del numero de usuarios,podremos hacerlo manualmente(no recomendado) o mediante Shell Script o Perl.
1.3.4 Filtros envio,cabeceras...etc.Importante.Debemos definir el tamaño maximo para el envio de emails,adjuntos,..etc, con el fin de bloquear los envios que superen X MB, y que puedan provocar una caida del rendimiento en el servidor.
1.3.5 Spam.Definir la politica.Emplearemos spamassassin(http://spamassassin.apache.org/) para filtrar el correo basura.Spamassassin para un correcto funcionamiento necesita "entrenamiento", para ello, debemos enviar directamente los emails a una carpeta llamada X(SPAM por ejemplo) dentro de cada buzon IMAP(con procmail es muy facil).Con CRON es muy facil añadir una tarea HAM y SPAM para que Spamassassin aprenda cual es realmente el SPAM(No deseado) y el HAM(Deseado) en las horas de menor carga de trabajo del server o servers.
1.3.6 Antivirus.[Pendiente]
1.3.7 Backup.Mirroring,tar.gz,Backula,DLT,DDS o lo que queramos, pero este punto es imprescindible en cualquier instalacion.
1.3.8 Monitorizacion.Si tenemos Nagios(www.nagios.org) en nuestra LAN/WAN tendremos la mitad del trabajo hecho en lo que se refiere a monitorizacion en tiempo real.La examinar el mail.log(en Debian) o maillog(en RHEL) podemos utilizar pflogsumm(jimsun.linxnet.com/postfix_contrib.html) y munin(http://munin.projects.linpro.no/) para obtener mediante el empleo del algoritmo Round Robin, unas estadisticas graficas detalladas y elegantes.

...

En relación al post anterior el concierto muy bien. Por causa relacionadas a mi situación mental el día del concierto, me he perdido a Ktulu.Koma; lo mejor. SA; en su línea. Habeas Corpus;no me gustaron.
De lo que he leído últimamente lo mas interesante:
.- Entrevista a Linus Torvalds
.- Kirai en meneame.
Kirainet.com es uno de los blogs más interesantes que he leído en mis casi 10 años como internauta.100% recomendado
.- Aokigahara : el bosque de los suicidios.

El próximo viernes 30 me voy con Pableras a la II LudusParty, en Lugo. Os mantendré informados.
Salud y gnuismo para todos.