Archivo

Posts Tagged ‘Ansible’

SACK Panic – CVE-2019-11477 – Multiple TCP-based remote denial of service

junio 18, 2019 Deja un comentario

Se ha detectado una nueva vulnerabilidad en Linux

https://access.redhat.com/security/vulnerabilities/tcpsack

Red Hat ha liberado un script para ver si nuestors sistemas están afectados:

https://access.redhat.com/sites/default/files/cve-2019-11477–2019-06-17-1629.sh

Para mitigar la vulnerabilidad podemos aplicar alguno de los siguientes parches:


Option #1
Disable selective acknowledgments system wide for all newly established TCP connections.

# echo 0 > /proc/sys/net/ipv4/tcp_sack

or

# sysctl -w net.ipv4.tcp_sack=0

This option will disable selective acknowledgements but will likely increase the bandwidth required to correctly complete streams when errors occur.
To make this option persist across reboots, create a file in /etc/sysctl.d/ such as /etc/sysctl.d/99-tcpsack.conf - with content:

# CVE-2019-11477 & CVE-2019-11478
net.ipv4.tcp_sack=0

Option #2 Mitigates CVE-2019-11477, CVE-2019-11478 and CVE-2019-11479 by preventing new connections made with low MSS sizes.

The default firewall configuration on Red Hat Enterprise Linux 7 and 8 is firewalld. To prevent new connections with low MSS sizes using firewalld use the commands.

# firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP
# firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP
# firewall-cmd --reload
# firewall-cmd --permanent --direct --get-all-rules

This firewall-cmd command will remain persistent through system reboots.
If using the traditional iptables firewalling method on any version of Red Hat Enterprise Linux, iptables equivalent command is:

# iptables -I INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP
# ip6tables -I INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP

# iptables -nL -v
# ip6tables -nL -v

Instalamos las dependencias del Playbook para poder configurar las reglas de IPTABLES permanentemente:


mkdir -p ~/.ansible/plugins/modules

wget -O ~/.ansible/plugins/modules/iptables_raw.py https://raw.githubusercontent.com
/Nordeus/ansible_iptables_raw/master/iptables_raw.py

Playbook de Ansible para mitigarlo:


--

- name: Configure CVE-2019-11477 rule
hosts: all
tasks:
- name: "IPTABLES_RAW | Secure CVE-2019-11477"
iptables_raw:
name: "CVE-2019-11477"
rules: '-A INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP'

Anuncios

Introducción a Ansible – Playbooks II

junio 5, 2015 Deja un comentario

A continuación, especificaremos el Playbook que hicimos en el post anterior, más correctamente, pero ahora, modificaremos el reinicio del servicio NTP, y lo incluiremos dentro de la directiva “handlers”, con esto, conseguiremos que el servicio únicamente se reinicie en caso de que se haya realizaro una modificación en el servidor con las dependencias anteriores, si no se ha modificado nada previamente, el servicio no será reiniciado.

---
- hosts: webservers
  vars:
    ntp_server: hora.rediris.es
  remote_user: root
  tasks:
  - name: Instalando ntpdate
    apt:
      name: ntp
      state: present
  - name: agregando el fichero de configuracion
    copy:
      src: /root/playbooks/ntp.conf
      dest: /etc/ntp.conf
  handlers:
  - name: reinicio sel servicio ntp para coger los cambios.
    service:
      name: ntp
      state: restarted

Como se puede ver, la definición de este Playbook es diferente del anterior, es la nueva forma de definición, la anterior, también está soportada y de momento parece que no la van a descontinuar.

Por otro lado, este Playbook, también tiene un inconveniente, y es que está preparado únicamente para servidores Debian o derivados, en caso de tener servidores CentOS dentro del grupo “webservers”, dará un error en la ejecución.
Para solventar este problema, modificaremos el Playbook de la siguiente manera.

---
- hosts: webservers
  vars:
    ntp_server: hora.rediris.es
  remote_user: root
  tasks:
  - name: Instalando ntpdate Debian
    apt:
      name: ntp
      state: present
    when: ansible_distribution == 'Debian' or ansible_distribution == 'Ubuntu'
  - name: Instalando ntpdate CentOS
    yum:
      name: ntp
      state: present
    when: ansible_distribution == 'CentOS' or ansible_distribution == 'Red Hat Enterprise Linux'
  - name: agregando el fichero de configuracion
    copy:
      src: /root/playbooks/ntp.conf
      dest: /etc/ntp.conf
  handlers:
  - name: reinicio sel servicio ntp para coger los cambios.
    service:
      name: ntp
      state: restarted

En este caso, como vemos la ejecución ha dado un error, ya que es una distribución mínima de CentOS y no tiene instalado Python.

root@master:~/playbooks# ansible-playbook ntp.yml

PLAY [webservers] *************************************************************

GATHERING FACTS ***************************************************************
ok: [192.168.49.42]
ok: [192.168.49.43]

TASK: [Instalando ntpdate Debian] *********************************************
skipping: [192.168.49.43]
ok: [192.168.49.42]

TASK: [Instalando python CentOS] **********************************************
skipping: [192.168.49.42]
ok: [192.168.49.43]

TASK: [Instalando ntpdate CentOS] *********************************************
skipping: [192.168.49.42]
ok: [192.168.49.43]

TASK: [agregando el fichero de configuracion] *********************************
ok: [192.168.49.42]
changed: [192.168.49.43]

PLAY RECAP ********************************************************************
192.168.49.42              : ok=3    changed=0    unreachable=0    failed=0
192.168.49.43              : ok=4    changed=1    unreachable=0    failed=0
Categorías:Administración, General Etiquetas: , ,

Introducción a Ansible – Playbooks I

junio 3, 2015 Deja un comentario

 

Los Playbooks son los ficheros de configuración, despliegue y orquestación. En ellos describimos las políticas que queremos aplicar a nuestros servidores.

La ventaja de utilizar playbooks sobre comandos online como hemos visto previamente, es que las políticas quedan guardadas, y pueden ser mucho más complejas.

A continuación, mostraré como pasar un ejemplo simple como los que hemos visto previamente, a un Playbook.

 

En el siguiente ejemplo, podemos ver como se realiza la instalación del servicio “ntp” en el grupo de servidores “webservers”

 

# ansible webservers -m apt -a "name=ntp state=present"

 

A continuación, mostramos como sería esto en un fichero de playbook.

 

---
- hosts: webservers
  tasks:
    - name: Instalando ntpdate
      apt: name=ntp state=present

Vemos que se define el grupo de servidores con la directiva “hosts”, y tenemos la etiqueta “tasks” dentro de la cual van a ir todas las tareas a realizarse, en este caso, invocaremos el módulo apt, indicando que queremos que el servicio “ntp” se encuentre presente.

Para ejecutar el Playbook, lo haríamos con el siguiente comando

# ansible-playbook ntp.yml

Y veríamos la ejecución del mismo.

Una vez que sabemos hacer un Playbook simple, podemos añadir más complegidad al mismo, como el que se muestra a continuación.


# vi ~/playbooks/ntp.yml
---
- hosts: webservers
remote_user: root
vars:
ntp_server: hora.rediris.es
tasks:
- name: Instalando ntpdate
apt: name=ntp state=present

- name: agregando servidor al fichero de configuracion
shell: echo "server {{ ntp_server }}" >> /etc/ntp.conf

- name: reinicio sel servicio ntp para coger los cambios.
service: name=ntp state=restarted
---

En este Playbook vemos que se indica el usuario remoto a utilizar, también se definen variables que se utilizarán posteriormente en el Playbook.
En el apartado de tareas, se realiza la instalación del servicio “ntp” con el módulo apt, posteriormente se agrega un nuevo servidor de tiempo en el fichero de configuración, y se reinicia el servicio con el módulo “service”.

Este sería el resultado de la ejecución del Playbook.

root@master:~/playbooks# ansible-playbook ntp.yml
PLAY [webservers] *************************************************************

GATHERING FACTS ***************************************************************
ok: [192.168.1.11]

TASK: [Instalando ntpdate] ****************************************************
changed: [192.168.1.11]

TASK: [agregando servidor al fichero de configuracion] ************************
changed: [192.168.1.11]

TASK: [reinicio sel servicio ntp para coger los cambios.] *********************
changed: [192.168.1.11]

PLAY RECAP ********************************************************************
192.168.1.11               : ok=4    changed=3    unreachable=0    failed=0

Con esto ya tenemos el servicio “ntp” configurado en nuestros clientes y funcionando.
Comentar que este Playbook tiene un problema, y es que cada vez que lo ejecutemos, nos creará una nueva linea en el fichero de configuración del servicio “ntp”, por lo que es recomendable, definir un fichero de configuración en el nodo master, y copiarlo posteriormente a los nodos.
Para eso es recomendable tener el fichero de configuración en el servidor local, modificar la linea del módulo “shell” por el módulo “copy” para copiar el fichero de configuración por scp.

copy: src=/root/playbooks/ntp.conf dest=/etc/ntp.conf

Una vez copiado, podríamos agregar otra tarea para modificar los permisos del fichero.

 

file: dest=/etc/ntp.conf mode=644 owner=root group=root

El Playbook final quedaría de la siguiente forma.


---
- hosts: webservers
remote_user: root
vars:
ntp_server: hora.rediris.es
tasks:
- name: Instalando ntpdate
apt: name=ntp state=present

- name: agregando el fichero de configuracion
copy: src=/root/playbooks/ntp.conf dest=/etc/ntp.conf

- name: Modificando permisos del fichero de config
file: dest=/etc/ntp.conf mode=644 owner=root group=root

- name: reinicio sel servicio ntp para coger los cambios.
service: name=ntp state=restarted

Introducción a Ansible IV – Ejecutar comandos ad-hoc en Ansible

mayo 15, 2015 Deja un comentario

Es posible ejecutar comandos independientes en Ansible, esto nos puede servir si no queremos crear un Playbook, que serían los scripts de ejecución masivos de Ansible.

– Ejecutar comandos de shell

Para ejecutar un comando independiente, lo haríamos de la siguiente manera:

# ansible all -a "/bin/echo hello"
192.168.49.42 | success | rc=0 >>
hello

Por defecto, Ansible está configurado para lanzar 5 procesos/hilos en paralelo, si queremos que lance más, podemos forzarlo en la ejecución.

# ansible all -a "/bin/echo hello" -f 10

Por defecto, Ansible ejecuta el módulo “shell”, que es el que ejecuta el comando, pero también podemos indicar que módulo queremos ejecutar.

# ansible all -m shell -a "/bin/echo hello" -f 10

– Transferencia de ficheros

Otra posibilidad, es realizar una copia masiva de ficheros a través de scp, para eso, utilizaremos el módulo copy

# ansible all -m copy -a "src=/etc/hosts dest=/tmp/hosts2"

Una vez hemos copiado el fichero, podemos cambiar los permisios y privilegios del mismo.

# ansible webservers -m file -a "dest=/tmp/hosts2 mode=600"
# ansible webservers -m file -a "dest=/tmp/hosts2 mode=600 owner=user group=user"

El cambio de permisos y privilegios también se puede realizar directamente desde el copiado de los ficheros.

por último, también podemos gestionar el borrado de ficheros y directorios, tener en cuenta que el borrado de directorios es recursivo.

# ansible webservers -m file -a "dest=/tmp/hosts2 state=absent"

– Gestión de paquetes.

Podemos gestionar los paquetes en yum y apt, por ejemplo podemos verificar si un paquete se encuentra instalado, en caso de no estar instalado, realizará la instalación.

# ansible webservers -m apt -a "name=screen state=present"

También podemos verificar que se encuentre en una versión específica.

# ansible webservers -m apt -a "name=screen-4.2.1 state=present"

O que está en la última versión

# ansible webservers -m apt -a "name=screen state=latest"

Por último, también podemos desinstalar un paquete que se encuentre instalado.

# ansible webservers -m apt -a "name=screen state=absent"

– Gestión de usuarios y grupos.

También podemos gestionar los usuarios y grupos de los equipos.

Podemos modificar o crear un usuario con el siguiente comando.

# ansible all -m user -a "name=usuario password=`openssl passwd -1 -salt `date +%N`  "password"`"

Para eliminar un usuario lo haríamos de la siguiente manera.

# ansible all -m user -a "name=usuario state=absent"

En el siguiente enlace se pueden consultar todos los módulos disponibles para Ansible.

http://docs.ansible.com/list_of_all_modules.html

– Gestión de servicios

También podemos gestionar los servicios de un servidor.

Podemos asegurar que un servicio esté encendido, y si no lo está encenderlo.

# ansible webservers -m service -a "name=networking state=started"

También podemos reiniciar los servicis en caso de haber aplicado un nuevo fichero de configuración.

# ansible webservers -m service -a "name=networking state=restarted"

Por último, podemos parar un servicio en caso de no querer que siga iniciado.

# ansible webservers -m service -a "name=httpd state=stopped"

Introducción a Ansible III – Patrones en Ansible

mayo 8, 2015 Deja un comentario

Los patrones en Ansible se utilizan para decidir que nodos queremos gestionar. Esto implica a que nodos queremos aplicar las configuraciones.
Un patrón tiene la siguiente estructura

ansible <pattern_goes_here> -m <module_name> -a <arguments>

Por ejemplo, si queremos reiniciar el servicio http en el grupo definido previamente de webservers, ejecutaríamos el siguiente comando

ansible webservers -m service -a "name=httpd state=restarted"

Como patrón, o nodos a los que lanzar los comandos, podemos utilizar también los siguientes patrones

all	#Todos los nodos
*	#Todos los nodos

nodo1.dominio.com	#Solo un nodo
192.168.0.20		#Solo un nodo

webservers:dbservers	#Que esté en cualquiera de los dos grupos (OR)

webservers:!ntpservers	#Que esté en webservers pero que no aparezcan en ntpservers

webservers:&ntpservers	#Que esté en webservers y que aparezcan en ntpservers
Categorías:Administración, HPC Etiquetas: , ,

Introducción a Ansible II – Primera conexión desde el master a los servidores

mayo 3, 2015 Deja un comentario

Para realizar las conexiones a los servidores, Ansible utiliza por defecto claves ssh para realizar la conexión a los nodos, por eso primero tenemos que generar una clave en el servidor y exportarla a los nodos.

Creación de claves en el nodo master

root@master:~/ansible# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
e9:7f:f0:ea:25:6d:b0:8a:26:39:8d:09:bd:f6:9d:70 root@master
The key's randomart image is:
+---[RSA 2048]----+
|                 |
|                 |
|                 |
|         .       |
|   .    S .      |
|  . .  .  .+     |
|   . *. E oo+    |
|    O o= + +o    |
|   . =o +.+o     |
+-----------------+

Exportación de claves a los clientes.

root@master:~# ssh-copy-id 192.168.1.11
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@192.168.1.11's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '192.168.1.11'"
and check to make sure that only the key(s) you wanted were added.

Una vez que tenemos las claves exportadas, podemos comprobar la conexión entre el master y los clientes, para eso vamos a utilizar un simple ping de momento.

# ansible all -m ping
192.168.1.11 | success >> {
    "changed": false,
    "ping": "pong"
}

Si por el contrario no queremos exportar los certificados, podemos forzar a que Ansible nos pregunte la contraseña para realizar la conexión a los clientes, aunque para esto tendremos que instalar previamente la aplicación “sshpass”.

# apt-get install sshpass -y
# ansible all --ask-pass -m ping
SSH password:
192.168.1.11 | success >> {
    "changed": false,
    "ping": "pong"
}

También podemos forzar la conexión a los equipos remotos con un usuario diferente al que estamos utilizando.

# ansible all -m ping -u user --ask-pass

Por último, si nos autentificamos con un usuario específico es posible que queramos acceder a tareas administrativas, pasa eso podemos utilizar el flag “–sudo”

# ansible all -m ping -u user --ask-pass --sudo
Categorías:Administración, HPC Etiquetas: ,

Introducción a Ansible I – Configuración del Inventario

mayo 2, 2015 Deja un comentario

El inventario (inventory) es uan descripción de los nodos acesibles por Ansible. El inventario se define en un fichero de confirmación en formato INI, la ubicación predeterminada del fichero es /etc/ansible/hosts

El fichero puede tener definiciones de grupos [grupo], o simplemente definiciones de servidores.
Un grupo puede tener uno o más servidores.

[webservers]
web1.dominio.com
web2.dominio.com
192.168.1.2

[dbservers]
db1.dominio.com
db2.dominio.com

También se puede definir un rango de servidores

db[3:10].dominio.com
Categorías:Administración, HPC Etiquetas: ,