·Escapando Caracteres·

Mis razones para abandonar y no volver IBM Cloud

noreply@blogger.com (Unknown) — Thu, 21 Jan 2021 00:13:00 -0300

¡Hola!

Este post les quiero compartir mi experiencia usando este proveedor de servicios de cloud computing. A partir del título de esta entrada podrán deducir que dicha experiencia no fue buena. Y aquí brevemente les detallo los problemas con los que tuve que lidiar:

outage de más de 12 horas, dejando fuera de servicio toda la capa de classic infrastructure (máquinas virtuales) por problemas de refrigeración.
siguiendo con los outages, uno de ellos forzó que todas las máquinas virtuales se debieran reiniciar dejando en modo de solo lectura a los discos de dichas vms.
software desactualizado: el rescue mode de las máquinas virtuales (devices) es... ¡CentOS 5!
y a causa de los dos puntos anteriores, me vi forzada a entrar máquina por máquina en modo rescate (se activa desde la ui) y a correr fsck sobre cada disco virtual.
fsck de recue mode es tan obsoleto que tuve que compilar e2fscprog desde sources.
la ui de IBM cloud es lenta y confusa. Una máquina virtual está encendida y completamente accesible pero el estado que muestra la interfaz web indica que está encendida pero desconectada.
cambiar de email es problemático, ya que posiblemente se pierda acceso a ciertos servicios porque el correo está vinculado a ellos.
debido a lo anterior no puedo acceder a uno de los clusteres de kubernetes (el cluster role binding no se actualiza como debiera y sigue vinculando el viejo email y no el nuevo).
no es posible (o al menos no encontré una manera) asignar roles a recursos. Por ejemplo: que una máquina virtual tengas permisos de lectura/escritura sobre un bucket. Necesariamente hay que crear un par de keys para tal propósito.

Estas razones son suficientes para pensar en migrar a otro proveedor más robusto y confiable.

Si alguien tuvo experiencias similares, los invito a compartirlas en los comentarios.

¡Saludos!

Me gusta GnuPG

noreply@blogger.com (Unknown) — Tue, 21 Jul 2020 22:10:00 -0300

¡Buenas noches!

Les comparto una presentación que hice hace varios años sobre GnuPG, una herramienta muy potente para manejo de claves. Si bien, como dije, la presentación fue realizada hace un tiempo, a mi me resultó útil para repasar algunos comandos básicos. Espero que sea útil para ustedes también.

https://docs.google.com/presentation/d/156yLcYEwsTCHlbMYf6ohJsfUjpzAqD326P4DeFwXiM8/edit?usp=sharing

Saludos.

Mi primeros pasos con Terraform

noreply@blogger.com (Unknown) — Sun, 12 Jul 2020 02:02:00 -0300

Buenas noches,

Estos últimos días empecé a probar Terraform, en particular para manejar servicios que tengo corriendo en Linode, que es un proveedor cloud bastante intersante en especial por su bajo costo y con muchísimos servicios ideales para desplegar infra escalable de manera bastante simple.

Al provider de Linode para Terraform lo pueden encontrar aquí.

Mi objetivo es crear una serie de buckets para backups, así que me puse en la tarea de escribir un módulo bastante sencillo (recomiendo leer la siguiente guía para arrancar).

$ tree 
.
├── main.tf
├── modules
│   ├── buckets
│       ├── main.tf
│       ├── outputs.tf
│       └── variables.tf
├── sensitive.tfvars
├── terraform.tfvars
└── variables.tf

En donde el main.tf luce de la siguiente manera:

provider "linode" {
  version = "~> 1.6"
  token = var.token
}

module "buckets" {
  source = "./modules/buckets"
  label = var.label
  region = var.region
  key_label = var.key_label
}

variables.tf

variable "region" {
  type = string
  description = "Default region"
  default = "us-central"
}

variable "label" {
  type = string
  description = "The bucket label"
  default = "default_label"
}

variable "key_label" {
  type = string
  description = "Object storage access key"
  default = "access_key"
}

variable "token"{
}

terraform.tfvars

label = "backup"
region = "us-east"
key_label = "backups_key"

sensitive.tfvars

token = "abcdefghi="

Finalmente, dentro del directorio buckets tengo lo siguiente:

main.tf

data "linode_region" "region" {
  id = var.region
}

data "linode_object_storage_cluster" "primary" {
  id = "${data.linode_region.region.id}-1"
}

resource "linode_object_storage_key" "bucket_key" {
  label = var.key_label
}

resource "linode_object_storage_bucket" "bucket" {
  cluster = data.linode_object_storage_cluster.primary.id
  label = var.label
}

variables.tf

variable "region" {
  type = string
  description = "Default region"
  default = "us-east"
}

variable "label" {
  type = string
  description = "The bucket label"
  default = "bucket_label"
}

variable "key_label" {
  type = string
  description = "Object storage access key"
  default = "bucket_key"
}

outputs.tf

output "bucket_label" {
  value = linode_object_storage_bucket.bucket.label
}

output "bucket_key" {
  value = linode_object_storage_key.bucket_key.label
}

Bastante sencillo, si. Antes de desplegar los cambios ejecutar:

$ terraform plan -var-file="sensitive.tfvars" -var-file="terraform.tfvars"

para saber qué va a hacer Terraform (crear, modificar o borrar un recurso).

Para finalmente aplicarlos

$ terraform apply -var-file="sensitive.tfvars" -var-file="terraform.tfvars"

Espero que haya sido de utilidad, estos son mis primeros pasos utilizando esta herramienta. Próximamente actualizaré mi repositorio incluyendo los templates para crear linodes.

Saludos.

.vimrc para tu vim

noreply@blogger.com (Unknown) — Tue, 19 Nov 2019 21:24:00 -0300

¡Hola!

Les comparto mi archivo .vimrc con todas mis configuraciones para usar con el editor Vim, espero que les sirva!

Templates anidados en Cloudformation

noreply@blogger.com (Unknown) — Tue, 23 Jul 2019 20:26:00 -0300

Buenas noches!

Uno de los problemas con los que me enfrenté cuando empecé con Cloudformation fue que creaba stacks con recursos demasiado grandes, de manera que si este fallaba en la creación de alguno de esos recursos, automáticamente AWS realiza el rollback, destruyendo todos los creados anteriormente. ¿Qué problemas implica esto? Principalmente pérdida de tiempo,además de tener un stack de recursos poco mantenible.

Una forma práctica y correcta al momento de provisionar recursos con Cloudformation es crear templates atómicos y reutilizables.

Ejemplo: se necesita levantar Grafana en docker, dos containers (distintas AZ) y un load balancer. Se usará ECS Fargate para tal propósito. De la descripción anterior se deduce que se requieren los siguientes recursos:

security groups, tanto para el ALB como para la aplicación
un ALB, con su respectivo target group y listener
una task y un service definition de ECS Fargate y un log group

Cada uno de estos grupos de recursos estarán definidos en templates diferentes, que serán los child.
La estrategia consiste en crear un template al que llamaremos master.yml que lucirá de la siguiente manera:

---
AWSTemplateFormatVersion: '2010-09-09'
Description: >
  Master template for Grafana hosted on Fargate

Parameters:
  S3Location:
    Description: Your S3 location to store cloudformation template
    Type: String
    Default: "https://s3-us-west-2.amazonaws.com/cf-grafana/"
    MinLength: 1

Resources:
  SecurityGroups:
    Type: AWS::CloudFormation::Stack
    Properties:
      Parameters:
        VPCId: ""
        EnvironmentName: ""
        Stage: ""
        ProjectName: ""
      TemplateURL: !Join ["",[!Ref S3Location, "sec-groups.yml"]]

  LoadBalancers:
    Type: AWS::CloudFormation::Stack
    Properties:
      Parameters:
        EnvironmentName: ""
        Stage: ""
        ProjectName: ""
        VPCId: ""
        Subnets: ""
        ALBSecurityGroup: ""
        HealthCheck: /api/health
      TemplateURL: !Join ["",[!Ref S3Location, "load-balancers.yml"]]

  ECS:
    Type: AWS::CloudFormation::Stack
    Properties:
      Parameters:
        Subnets: ""
        #RepositoryURL: ""
        SecurityGroups: ""
        TargetARN: ""
        ClusterName: ""
        LogPrefix: ""
        EnvironmentName: ""
        Stage: ""
        ProjectName: ""
        LogGroupName: "ecs"
      TemplateURL: !Join ["",[!Ref S3Location, "ecs.yml"]]
...

Del template anterior se puede destacar que es necesario disponer de un bucket S3 donde guardar los templates referenciados luego.

Cada Resource es del tipo AWS::CloudFormation::Stack y es allí donde se llaman a los stacks de los recursos que necesitamos crear.

Algo interesante es que desde el archivo master se pueden pasar Parameters a cada child, de manera que esos templates hijos no estarán harcodeados y podrán ser reutilizados en otra implementación. Teniendo todo esto listo, ya se puede realizar el deploy de los recursos ¿Cómo? Comentando cada sección de Stacks. Esto sería, comentar el Stack LoadBalancers y ECS; posteriormente, cuando se actualiza el template master, descomentar lo que corresponde a LoadBalancers (Cloudformation no modificará ni destruirá nada de lo anterior). Por último ECS.

Espero que haya sido de utilidad.

Errores con mirrors de Raspberry Pi

noreply@blogger.com (Unknown) — Sat, 15 Jun 2019 16:33:00 -0300

Buenas tardes,

Quienes usen Raspberry Pi con Raspbian) (o cualquier SO basado en Debian) e intenten instalar paquetes posiblemente experimentan el siguiente error:

E: Fallo al obtener http://espejito.fder.edu.uy/raspbian/raspbian/pool/main/d/db-defaults/libdb-dev_5.3.1_armhf.deb  La suma hash difiere
   Hashes of expected file:
    - SHA256:758a865f81496e5dc4742467ea65b2587b2f5701da22aabdb9ef0390f59cad5d
    - SHA1:668819cadbe14928bc627c698a56002a2c097441 [weak]
    - MD5Sum:bec8cd7801c05645ade55d73281de814 [weak]
    - Filesize:2348 [weak]
   Hashes of received file:
    - SHA256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
    - SHA1:da39a3ee5e6b4b0d3255bfef95601890afd80709 [weak]
    - MD5Sum:d41d8cd98f00b204e9800998ecf8427e [weak]
    - Filesize:0 [weak]
   Last modification reported: Mon, 31 Aug 2015 12:10:16 +0000
E: No se pudieron obtener algunos archivos, ¿quizás deba ejecutar «apt-get update» o deba intentarlo de nuevo con --fix-missing?

Para resolver este problema decidí modificar el archivo source.list cambiando el mirror que originalmente es:

deb http://raspbian.raspberrypi.org/raspbian/ stretch main contrib non-free rpi

por el siguiente:

deb http://mirror.ufam.edu.br/raspbian/raspbian/ stretch main contrib non-free rpi (Brasil)

Evidentemente el error es causado por la misma caché del repositorio.
Aquí la lista de mirrors: https://www.raspbian.org/RaspbianMirrors/

Muchas páginas/blogs sugieren realizar también lo siguiente (no funcionó en mi caso):

1- sudo apt-get clean
2- sudo apt-get autoclean
3- sudo rm -Rf /var/lib/apt/lists/* (recomendado)

Saludos.

Taller de Pelican, by LinuxchixAr

noreply@blogger.com (Unknown) — Mon, 1 Apr 2019 20:15:00 -0300

Hola!

Este mes con LinuxchixAr estaremos brindando un taller dedicado a Pelican, un generador de contenido estático puramente basado en Python.

A partir de hoy las inscripciones se encuentran abiertas!

Formulario: https://t.co/1Bt15UECAn
Meetup: https://t.co/VK5iACMzUa

Te invito también a seguir a la comunidad LinuxchixAr en las redes sociales para que estés al tanto de todas las actividades que vamos a realizar.

http://www.linuxchixar.org/

Template de Cloudformation para crear outbound endpoints y rules en Route53

noreply@blogger.com (Unknown) — Mon, 4 Mar 2019 22:07:00 -0300

Hola!

Les comparto un template de Cloudformation que tuve que escribir para crear outbound endpoints y sus correspondientes rules. Todo esto corresponde al servicio Route53.

Hago uso de !ImportValue, una funcionalidad excelente que me permite importar de otros stacks que estén en la misma región algunos valores que necesito para crear el mío.

Seguramente necesita pulirse algunos detalles, como agregar parámetros para las direcciones IP y así evitar que estén harcodeadas. Espero que les resulte útil y aguardo sus sugerencias.

---
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Template used to create outbound endpoints and rules to reach 
  external DNS servers'
Parameters:
Resources:
  OutboundEndpoint:
    Type: "AWS::Route53Resolver::ResolverEndpoint"
    Properties:
      Direction: Outbound
      IpAddresses:
        - 
          SubnetId: !ImportValue 'VPCStack-SubnetA'
        - 
          SubnetId: !ImportValue 'VPCStack-SubnetB'
      Name: OutboundEndpoint
      SecurityGroupIds: 
        - Ref: OutboundSecurityGroup
      Tags:
        - 
          Key: 'Name'
          Value: 'OutboundEndpoint'
  OutboundSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow outbound traffic
      SecurityGroupEgress:
        - IpProtocol: udp
          FromPort: '0'
          ToPort: '53'
          CidrIp: '0.0.0.0/0'
      VpcId: !ImportValue 'VPCStack-VpcId'
      Tags:
        -
          Key: 'Name'
          Value: 'OutboundSecurityGroup'
  OutboundResolverRules:
    Type: "AWS::Route53Resolver::ResolverRule"
    Properties:
      DomainName: 'domain.net'
      Name: 'DomainNetRules'
      ResolverEndpointId: !GetAtt OutboundEndpoint.ResolverEndpointId
      RuleType: 'FORWARD'
      Tags: 
        -
          Key: 'Name'
          Value: 'DomainNetRules'
      TargetIps: 
        - 
          Ip: ''
          Port: '53'
        - 
          Ip: ''
          Port: '53'
    DependsOn: OutboundEndpoint
  ResolverVPC:
    Type: "AWS::Route53Resolver::ResolverRuleAssociation"
    Properties:
      Name: ResolverRuleDNS
      ResolverRuleId: !GetAtt OutboundResolverRules.ResolverRuleId
      VPCId: !ImportValue 'VPCStack-VpcId'
    DependsOn: OutboundResolverRules
Outputs:
    ResolverEndpointId:
      Description: Resolver endpoint ID
      Value: !GetAtt OutboundEndpoint.ResolverEndpointId
      Export:
        Name: !Sub '${AWS::StackName}-ResolverEndpointId'
    ResolverRuleId:
      Description: Resolver rule ID
      Value: !GetAtt OutboundResolverRules.ResolverRuleId
      Export:
        Name: !Sub '${AWS::StackName}-ResolverRuleId'
...

Referencias: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-route53resolver-resolverendpoint.html

Integrar Telegraf con scripts personalizados para crear monitoreo y gráficos

noreply@blogger.com (Unknown) — Tue, 19 Feb 2019 00:02:00 -0300

Hola!

Algo que me parece super interesante de Telegraf es la facilidad con la que se pueden integrar scripts custom para la recolección de métricas a través del plugin exec.

Recientemente me vi en la tarea de generar gráficos en Grafana en los que pueda visualizar la cantidad de conexiones activas de los usuarios conectados a una base de datos MySQL (o MaríaDB). Con Telegraf es muy simple (y sin usar un cron que corra cada minuto que ejecute el script y escriba los datos en una db). Si bien al script lo tuve que escribir yo, únicamente me tuve que preocupar que el STDOUT del script sea el que espera Telegraf. Dado que mi motor de base de datos en InfluxDB, el formato de dicha salida del script tiene que ser influx.

Mi script se ejecutaba de la siguiente manera y devolvía un output:

$ ./users_connections.py

active_connections,host=mydb.example.net user=user1,active_conns=1234

active_connections,host=mydb.example.net user=user2,active_conns=1235
active_connections,host=mydb.example.net user=user3,active_conns=1236
active_connections,host=mydb.example.net user=user4,active_conns=1237

El archivo de configuración de Telegraf /etc/telegraf/telegraf.conf tendrá una sección para este script:

[[inputs.exec]]
  ## Commands array
  commands = [
    "/scripts/users_connections.py",
  ]
  timeout = "5s"
  name_suffix = "_activeconns"
  data_format = "influx"

Si agregan otros scripts a esta misma sección automáticamente Telegraf los ejecutará sin necesidad de reiniciar el servicio.

¡Espero que sea de utilidad!

Deploy de public keys con Ansible

noreply@blogger.com (Unknown) — Sun, 10 Feb 2019 03:32:00 -0200

Hola!

Quienes usamos o empezamos a usar Ansible nos preguntamos cómo instalar la clave pública en los hosts (que pueden ser muchos) que queremos manejar a través de Ansible... usando Ansible mismo :)

La respuesta la encontré a través de un playbook que luce de la siguiente manera:

$ cat deploy_ssh_key.yml  
1:  ---  
2:  - hosts: all  
3:   gather_facts: false  
4:   vars_files:  
5:    - external_vars.yml  
6:   tasks:  
7:   - name: Create direcotry  
8:    file:  
9:     path: "/home/usuario-remoto/.ssh"  
10:     state: directory  
11:   - name: Create empty file  
12:    file:  
13:     path: "/home/usuario-remoto/.ssh/authorized_keys"  
14:     state: touch  
15:   - name: Put pubkey  
16:    lineinfile:  
17:     path: "/home/usuario-remoto/.ssh/authorized_keys"  
18:     line: "{{ pub_key }}"

El archivo external_vars.yml contiene la clave pública:

 $ cat external_vars.yml  
 ---  
 pub_key: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCnTvKiRzIU0Jqz3kpf97wVJdT4LwHZuu6Nr/GFFOtq0QeWP5Eu6JmWkvwuNoghdXu/lxHf//07djGUfxnt9BDdQmDMsGx3qEFzAQAlrlq2P6lygSksy8MROQsHCDzT0hX7pntiwigDE7rUuGt3h3T+IFuvjfZqMx2wiX4dFLUC9+HcdtUuzMHjMs1zevP2nmpOWAP7LkcwlkdJZIpkOqujshJFymuXylWvT8vV5RbqwB7ZaR1m+rpCYt1MQFgHgI/42jXeywbORA3Nm6pjVCccNjJ5DpbhiEZA/O/SJH/zlFPuoPaTai5sH8MLuU8h11C4U9UPY08/XhAkIDebVri1 ansible@verovan.com.ar  
 ...

El comando de Ansible se ejecuta de la siguiente manera:

 $ ansible-playbook -u usuario-remoto deploy_ssh_key.yml --ask-pass -c paramiko

(-c paramiko lo usé debido a un issue reportado en https://github.com/ansible/ansible/issues/3564)

Para verificar que está todo en orden y que la clave fue instalada correctamente:

 $ ansible all -u usuario-remoto --private-key-file=/ruta/a/la/clave-privada -m ping

El módulo lineinfile lo usé para apendar la clave pública en el archivo authorized_keys (ver https://docs.ansible.com/ansible/latest/modules/lineinfile_module.html)

Espero que les resulte de utilidad!

NOTAS ADICIONALES

Si se deploya las keys en CentOS 6, es necesario cambiar los permisos tanto del fichero authorized_keys como del directorio .ssh. El playbook quedaría de esta manera:

 ---  
 - hosts: curso  
  gather_facts: true  
  vars_files:  
   - external_vars.yml  
  tasks:  
  - name: make direcotry  
   
   file:  
    path: "/home/usuario-remoto/.ssh"  
    state: directory  
   
  - name: create empty file  
   file:  
    path: "/home/usuario-remoto/.ssh/authorized_keys"  
    state: touch  
   
  - name: put pubkey  
   lineinfile:  
    path: "/home/usuario-remoto/.ssh/authorized_keys"  
    line: "{{ pub_key }}"  
   
  - name: change permissions file  
   file:  
    path: "/home/usuario-remoto/.ssh/authorized_keys"  
    mode: 0600  
   when: ansible_distribution == "CentOS"   
   
  - name: change permissions dir  
   file:  
    path: "/home/usuario-remoto/.ssh"  
    mode: 0700  
   when: ansible_distribution == "CentOS"

Algo simple con rsync

noreply@blogger.com (Unknown) — Thu, 31 Jan 2019 00:50:00 -0200

Hola!

Voy a contarles una forma muy sencilla de hacer respaldos de sus archivos/fotos/lo que sea, que tienen almacenadas en su celular y no quieren subirlas a la nube (mi caso).
Con rsync encontré la forma de lograr eso. Para tal fin necesité lo siguiente:

rsync configurado y ejecutándose en la computadora donde deseo almacenar los archivos
la aplicación myRsync https://github.com/socratesx/myrsync instalada en el teléfono

Configurar rsync es sumamente simple para nuestro propósito. Se debe editar (o crear en caso que no existiese) el archivo /etc/rsyncd.conf con el siguiente contenido (puede llevar otras opciones, consultar man rsyncd.conf)

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
port = 12000

[celular]
path = /home/verovan/celular
comment = my photos mobile
read only = false
write only = false
timeout = 300
max connections = 2
uid = verovan
gid = verovan

Se debe reiniciar el servicio de rsync luego de editar el archivo de configuración. rsync se estará ejecutando como un demonio en el sistema.

Respecto al punto número 2, myRsync se encuentra disponible en el PlayStore, no tiene adds y es muy intuitiva. Una excelente ventaja es el scheduler, que no es más que un cron para ejecutar rsync desde el teléfono en días y horarios determinados y asociarlo a alguna configuración.

Configuration name: nombre para la configuración de rsync.
Server IP address: la IP de la compu/server donde se configuró el demonio de rsync
Rsync User: si se configuró un usuario en rsync en la pc/server usarlo, de otro modo será anonymous.
Rsync Server Mode: lo que colocamos entre corchetes en la configuración de rsync.

ADD PATH permite elegir sobre qué directorio del celular realizar el rsync.
En Rsync options yo uso -arzvt, pero dependerá de cada usuario.
Finalmente se puede visualizar el comando tal como si se estuviese desde un terminal y ejecutarlo para probar que esté todo correctamente configurado.

De esta manera estaremos realizando un respaldo de lo que queramos cuando queramos desde nuestro celular a nuestra propia pc/servidor :)

PROS: tenemos todo bajo nuestro control.
CONS: la aplicación myRsync no soporta SSH.
TIP: setear una IP estática en la pc/servidor destino, ya que el DHCP server del router puede asignarle una diferente a la que hayamos configurado en la aplicación.

¡Espero que sea de utilidad!

Más sobre rsync: https://download.samba.org/pub/rsync/rsyncd.conf.html

RMS en Jujuy. Sueño cumplido.

noreply@blogger.com (Unknown) — Wed, 14 Jun 2017 22:34:00 -0300

Buenas noches, lectores.

Creo que fueron unos días loquísimos desde el sábado que pasó hasta el martes. La llegada de Richard Stallman nos revolucionó a todos los amantes del software libre. Estar y charlar con alguien que cambió la historia de las ciencias de la información, creó una filosofía y generó un movimiento alrededor de todo el mundo, realmente pone la piel de gallina...

Me siento muy privilegiada por una oportunidad como esta. Y muy feliz de que mi querida Facultad de Ing., en la persona del Ing. Lores, se haya comprometido para que todo se llevara a cabo en el ámbito universitario e impulsado el otorgamiento del título de Doctor Honoris Causa.

Hay muchas anécdotas por contar, pero me quedo con el momento en el que, con rms, discutimos cómo intercambiar claves públicas :) Luego del almuerzo que preparé para el, le comenté acerca de mi charla sobre criptografía asimétrica y GnuPG. Fue un buen momento para seguir aprendiendo de la mano de un genio, un hacker...

Haber sido parte de la recepción de Stallman fue una oportunidad que me dio Luis Wayar. Luis es un referente y lo aprecio muchísimo. Una persona que hizo y hace mucho por el software libre en mi provincia y que merece el reconocimiento de todos, por su dedicación constante y su valioso aporte a toda la comunidad.

Con el excelente grupo que organizamos la estadía de Stallman en Jujuy, prontamente subiremos todo el contenido al sitio web creado exclusivamente para promocionar la visita de rms. No dejen de visitar http://stallmanenjujuy.org para que pueda ver fotos y vídeos (en formatos libres por supuesto :D ) y más material.

¡Saludos!

Pre-Stallman... y lo que se viene!

noreply@blogger.com (Unknown) — Tue, 6 Jun 2017 21:58:00 -0300

Buenas noches, lectores.

Están siendo semanas sobrecargadas de actividades de preparación para recibir a Richard Stallman nuevamente en la Argentina ¡Nada más ni nada menos! Jujuy no es la excepción a esta visita y, desde estas latitudes, estamos muy emocionados por su llegada.

Quienes formamos parte de la comisión que organiza su llegada, nos comprometimos en realizar una recepción fantástica. También, para comunicar a toda la población lo relacionado con la personas de rms, creamos el sitio web http://stallmanenjujuy.org/ en el cual dejamos toda la información que hay que saber para asistir a la charla magistral que brindará el día 12 de junio en las instalaciones de la Facultad de Ingeniería de la Universidad Nacional de Jujuy.

Entre las cosas que se realizaron, el Pre-Stallman fue el destacado. Con el fin de difundir la visita de rms, se llevó adelante una jornada a puro software libre. Para tal evento, di una charla acerca del Cifrado con GnuPG. Me pareció mucho más que oportuno hablar sobre esta herramienta que nos brinda confidencialidad e integridad en las comunicaciones y que es totalmente LIBRE.

En la página web que anteriormente mencionaba, serán publicadas todas las presentaciones que se llevaron adelante ese día... ¡realmente hubo excelentes charlas! Desde robótica con software libre hasta la explotación de la vulnerabilidad, se habló de muchísimas cosas sumamente interesantes. Los invito a repasar las presentaciones y poner en práctica algunas de las cosas que se muestran allí :)

¡Saludos!

Qué dificil es conformar a todos...

noreply@blogger.com (Unknown) — Thu, 18 May 2017 09:14:00 -0300

Buenos días, lectores.

El título de esta entrada de blog es una frase que todos debemos haber pronunciado alguna vez... porque es una realidad, totalmente innegable.

En mi actual posición de sysadmin, me encuentro administrando el servidor-router que conecta mi red local con internet. Y debo brindar acceso a todos los servicios de internet a casi 250 personas diariamente. Muchos dirán que tienen más usuarios en sus redes, pero estoy segura que aplican políticas de acceso a la web, especialmente, dado que es el servicio que mayor cantidad de tráfico de red genera y nuestros clientes consumen. Bueno... lo último no es mi caso.

Por supuesto, hay horarios críticos... y sitios que deben ser accedidos con la mayor prioridad posible... y personas a las que se les debe garantizar una muy buena navegación... y tratar que nadie sienta el acceso ralentizado a algunas páginas... y lidiar con problemas del proveedor de internet. Son muchas condiciones cuando se tienen 100 personas navegando libremente por la web, mirando vídeos, diarios, redes sociales, etc.

Escenario:

9Mbit de tráfico de bajada, 2Mbit de tráfico de subida.
Servicio Squid para acceso HTTP, HTTPS y eventualmente FTP.
Acceso a servicios comunes, como correo, FTP, DNS, etc.
Usuarios exigentes que no aceptan esperar unos segundos que la página cargue (sin excepción).

Solución

Dividir el tráfico de bajada, asignando un cierto ancho de banda para cada servicio utilizando tc del paquete iproute2.
Dedicar un ancho de banda a Squid y emplear delay_pools para ralentizar el acceso a ciertos sitios.
Monitorear el rendimiento.

Para el primer punto, mis reglas de tc quedarían como sigue:

 lan="eth1"
 red_local="192.168.0.0/24"
 pc1="192.168.0.2/32"
 nic_speed="900Mbit"
 download="9Mbit"
 gateway="192.168.0.1/32"
 # borrar todo
 tc qdisc del dev eth1 root  
 # qdisc por defecto 11  
 tc qdisc add dev $lan root handle 1:0 htb default 40  
 tc class add dev $lan parent 1:0 classid 1:1 htb rate $nic_speed ceil $nic_speed  
   # red local - acceso a internet: squid, dns, correo, ftp y otros  
   tc class add dev $lan parent 1:1 classid 1:10 htb rate $download ceil $download  
     tc class add dev $lan parent 1:10 classid 1:11 htb rate 5mbit ceil 8mbit prio 1 # squid  
     tc class add dev $lan parent 1:10 classid 1:12 htb rate 1024kbit ceil 1536kbit prio 2 # dns,correo,ftp,otro  
     tc class add dev $lan parent 1:10 classid 1:13 htb rate 1024kbit ceil 1536kbit prio 3 # otros  
 ######################################################################################  
 #------------------------------------scheduling--------------------------------------#  
 ######################################################################################  
 # asignación equitativa del ancho de banda  
 tc qdisc add dev $lan parent 1:11 handle 11: sfq perturb 10
 tc qdisc add dev $lan parent 1:12 handle 12: sfq perturb 10
 tc qdisc add dev $lan parent 1:13 handle 13: sfq perturb 10
 ######################################################################################  
 #----------------------------------- filtering --------------------------------------#  
 ######################################################################################  
 tc filter add dev $lan protocol ip parent 1:0 prio 1 u32 match ip src $gateway match ip dst $red_local match ip sport 3128 0xffff flowid 1:11 #squid 
 tc filter add dev $lan protocol ip parent 1:0 prio 1 u32 match ip dst $red_local match ip sport 20 0xffff flowid 1:12 #ftp
 .........
 tc filter add dev $lan parent 1:0 protocol ip prio 1 u32 match ip dst $pc1 flowid 1:13 #pc liberada

Con esto conseguí:

Asignarle a Squid un mínimo de 5Mbit y un máximo de 8 (en los horarios críticos, cuando todos se conectan, el consumo está a tope) .
Dedicar 1Mbit con máximo de 1.5Mbit para servicios como correo, DNS, etc.
Garantizarles a ciertos hosts que no utilizan Squid para acceso a la web y requieren un ancho de bajada dedicado.

Para el segundo punto, teniendo en cuenta que lo más consultado durante las horas críticas son diarios y redes sociales, mis delay_pools quedaron como sigue (omitiré muuuchas cosas del squid.conf):

 #------------------------------------------------  
 delay_pools 4  
 delay_initial_bucket_level 90  
 delay_class 1 1  
 delay_access 1 allow exten  
 delay_access 1 deny all  
 delay_parameters 1 100000/90000  
 delay_class 2 1  
 delay_access 2 allow youtube  
 delay_access 2 deny all  
 delay_parameters 7 35000/30000  
 delay_class 3 1  
 delay_access 3 allow facebook  
 delay_access 3 deny all  
 delay_parameters 8 35000/30000  
 delay_class 4 1  
 delay_access 4 allow diarios  
 delay_access 4 deny all  
 delay_parameters 4 90000/85000
 #------------------------------------------------

Como se ve, creé unos delay muy generosos para el acceso a las páginas definidas en las ACLs correspondientes, que son: exten (extensiones de archivos, como .exe, .iso, .rar, etc.), facebook, youtube y diarios.

Para el último punto, creé un script en bash para saber qué pasa con mi Squid...

 watch -n 3 "echo '===SQUID REAL TIME MONITOR===' && \  
  'Hosts connected: '; netstat -n | grep '\:3128' | awk '/ESTABLISHED/ {print \$5}' | cut -d: -f1 | sort | uniq -c | wc -l && \  
  echo 'NTLM helpers:'; pgrep -f ntlmssp | wc -l && \  
  echo 'Groups request:'; pgrep -f /usr/lib/squid3/ext_wbinfo_group_acl | wc -l && \  
  echo 'Winbind proceses: '; pgrep -f winbind | wc -l && \  
  echo 'Total GigaByte downloaded:'; awk '{sum += \$5} END {print (sum/1024^3)\" GB\"}' /var/log/squid3/access.log  
  echo 'Disk space usage: '; du -hs /var/log/squid3/ | awk '{print \$1}' &&   
  echo 'Disk space usage (in %) /var:'; df -h | egrep SYSTEM-var | awk '{print \$5}'  
  echo 'Disk space usage (in %) /spool:'; df -h | egrep SYSTEM-spool | awk '{print \$5}'  
  echo 'Queue rate for Squid traffic:'; tc -s -d -r -p class show dev eth1 classid 1:11 | egrep 'rate' | sed -n '$ p' | awk '{print \$1,\$2}'"

Dado que empleo autenticación para acceder a la caché, monitoreo la cantidad de helpers empleados para que Squid no se quede con solicitudes encoladas. También la cantidad de contenido descargado, espacio usado por los logs (no está demás, aunque teniendo un cron para logrotate bien configurado no tiene que haber problemas de espacio en disco), espacio usado por Squid en disco para almacenar sus objetos y, finalmente, un monitoreo del consumo de la class definida para Squid, para saber el rate que circula por esa disciplina.

Espero que esta entrada de blog les resulte útil. Me llevó tiempo entender muchas cosas de Traffic Control y Squid... hay mucho material en internet disponible para lectura que recomiendo que lo lean.

¡Saludos!

FLISoL 2017!

noreply@blogger.com (Unknown) — Tue, 25 Apr 2017 23:41:00 -0300

Buenas noches, lectores.

El título del post lo dice todo: el FLISoL 2017 tuvo lugar el Sábado 22 de abril en más de 50 sedes en la Argentina, y realmente no pasó para nada inadvertido.

Sin dudas es el evento más representativo del Software Libre en Latinoamérica. En su 13º aniversario, el número de sedes a lo largo del país fue sorprendente, y las repercusiones en las redes sociales dieron cuenta de ello.

Jujuy vivió esta fiesta del Soft Libre en cuatro ciudades: San Salvador de Jujuy, Ledesma, Perico y Tilcara; en esta última el equipo de USL Jujuy (@usljujuy) se puso al hombro la organización y fue un verdadero éxito. Niños y jóvenes se acercaron para disfrutar de charlas y talleres de diferentes temáticas. También, como no puede faltar en ningún FLISoL, se realizaron numerosas instalaciones de distintas distribuciones GNU/Linux en las PCs de los asistentes. Para los niños, se puso a disposición un arcade armado con Raspberry Pi y Retro Pie.

Les recomiendo leer esta bonita nota periodística sobre lo que nos dejó el 13º Festival Latinoamericado de Instalación de Software Libre en Tilcara, Jujuy:

http://eljujeño.com.ar/2017/04/23/una-verdadera-fiesta-de-las-tecnologias-libres-se-vivio-en-el-flisol-de-tilcara/

¡Saludos!

Jack The Stripper para Debian 8

noreply@blogger.com (Unknown) — Thu, 13 Apr 2017 18:23:00 -0300

Buenas tardes, lectores.

Hace unos años, Eugenia Bahit presento su herramienta llamada Jack The Stripper, que es un script en Bash que permite la configuración de un servidor Ubuntu 12.04, y que deploya en entorno LAMP de manera muy sencilla.

La verdad es que las cosas cambiaron un poco respecto a los paquetes, sobre todo en Apache, por lo que me puse manos a la obra para adaptar esta tool a la última versión de Debian, que es la 8 (también conocida como Jessie).

En mi repo de Github subí la actualización que realicé, haciendo unas modificaciones en los siguientes aspectos:

Firewall.
Configuración de SSH.
Configuración de Apache.
Configuración de mod_security.
Configuración de mod_evasive.
Inclusión de configuraciones de seguridad básicas.

En el README.md se explica cómo ejecutar esta herramienta, que es muy sencilla.

Ejecución de JTS en Debian 8

Quien esté interesado puede contribuir con este trabajo. Está licenciado bajo GPL v3.

¡Saludos!

Ransomware file extensions, de @kinomakino

noreply@blogger.com (Unknown) — Tue, 28 Mar 2017 19:13:00 -0300

Buenas tardes, lectores.

En esta oportunidad quisiera invitarlos a que se sumen al proyecto de @kinomakino que implementa una solución para evitar el ransomware para los servidores de archivos de Windows Server 2012, haciendo uso de herramientas propias del sistema. Acá más detalles: http://kinomakino.blogspot.com.ar/2016/04/como-evitar-el-cifrado-por-ransomware_21.html

Nos propone un sencillo script en Powershell que intenta evitar la propagación del cifrado de los archivos y carpetas que se almacenan en el servidor. El script se ejecuta como tarea programada y se encarga de actualizar el listado de extensiones... una preocupación menos ;)

En su repositorio de Github se encuentran tanto el script como el listado que ¡ya superó las 400!

También quiero recomendar este vídeo de la primera sesión de los ElevenPath Talks de la temporada 2017 titulado "La guerra contra el Ransomware".

¡Espero que les sea útil!

Saludos.

Commandline challenge

noreply@blogger.com (Unknown) — Mon, 20 Mar 2017 18:47:00 -0300

¡Buenas tardes, lectores!

Quiero compartir con uds. algo que me mantuvo entretenida un largo rato: se trata del CMD Challenge, que es una serie de desafíos que ponen a prueba el conocimiento y habilidad en la línea de comandos para resolver situaciones comunes que pueden presentarse a un programador, sysadmin, encargado de seguridad, etc.

La interfaz es muy sencilla: se tiene un intérprete bash en donde se ejecutan los comandos y más abajo están los retos. Al clickear en alguno de ellos, se muestra el instructivo del mismo en la consola.

A mi me queda aún un desafío por resolver, que me está quemando un poco las pestañas :P

Dejo mis respuestas aquí: http://pastebin.com/7y9WZTTz

Saludos!

Hardening Linux

noreply@blogger.com (Unknown) — Tue, 28 Feb 2017 23:48:00 -0300

Buenas noches, bloggeros.

Esta entrada está dedicada a comentar algunas prácticas que siempre llevo adelante al momento de instalar Debian (es mi distribución de cabecera). Están relacionadas con asegurar el server (o incluso tu computadora personal) de la mejor manera posible y reducir las brechas de seguridad además de otras cuestiones a tener en cuenta al momento de instalar el sistema operativo y su posterior mantenimiento.

Se sabe que no existe entorno 100% seguro pero al menos con estas recomendaciones se puede estar un poco más tranquilos de que el servidor tiene menos posibilidades de quedar comprometido por cualquier razón.

Sin más preámbulos, vamos a lo importante...

Seguridad física y control de acceso

Es importante contemplar si existe acceso físico al equipo. Si es así, tenemos un primer punto crítico de falla. El acceso a los servidores debería ser remoto. Si se requiere acceso físico a ellos, sólamente tiene que ser por parte de los administradores de la infraestructura. Aparte, sería bueno disponer acceso biométrico o por huella digital a la sala de servidores y cámaras que registren los movimientos dentro de la misma.
Idealmente se debería tener una sala separda "lógicamente", quiere decir, por ejemplo, que la infraestructura esté dividida en salas diferentes, líneas de racks, etc. Así, cada sala tendrá que contar con la seguridad física correspondiente.
A esto hay que sumar consideraciones sobre instalación eléctrica, orden en el cableado, ubicación de los equipos, separación de la línea de datos de la eléctrica, entre muchas cosas.

Proteger el BIOS/UEFI

Para evitar que algún intruso que, en caso que acceda físicamente al servidor, entre otras cosas, cambie la secuencia de booteo y acceda a través del modo rescue o monousuario.

Teniendo en cuenta lo anterior, ¡es importante deshabilitar periféricos no utilizados!

Instalación: Mejores prácticas (algunas)

Tipo de instalación (minimal/basic): si se elige Debian para instalar en el server, ¡utilizar la versión standard! No se necesita entorno gráfico ;)
Particionado del disco: se sugiere siempre separar los directorios /var, que almacena datos áltamente variables, con mucha actividad y que requiere ubicarse en almacenamientos rápidos como un RAID; /tmp almacena datos temporales, que son borrados por algunos procesos; /etc, que contiene archivos de configuración locales, propios de la máquina y /home, para datos del usuario.

Con el esquema general planteado anteriormente, podemos mejorar el tiempo de acceso a datos, facilitar la recuperación en caso de incidentes y minimizar los problemas por falta de espacio de almacenamiento.

Swap: es una partición que sirve, básicamente, para guardar las imágenes de los procesos que no se mantienen en la memoria física. Se recomienda que su tamaño sea igual al de la memoria RAM, aunque depende del caso.
¡Usar LVM! A través de esta gestión del almacenamiento por volúmenes lógicos, se tiene una visión de alto nivel sobre el almacenamiento de disco, muy diferente a lo que nos brinda el particionado tradicional. Ofrece flexibilidad para agregar nuevo almacenamiento, modificar el tamaño de los volúmenes, etiquetar los volúmenes de manera conveniente, crear snapshots, entre otra ventajas.

Prevenir combinación de reinicio (REISUB)

Este punto es discutible. Se puede presentar la situación que el sistema no responde... y en vez de hacer un reinicio forsozo, utilizar una de las Magic Keys y generar un reinicio ordenado para que el administrador respire tranquilo. Pero si alguien accede físicamente a nuestro servidor, puede utilizar esta combinación de teclas para reiniciar el equipo y bootear desde otro dispositivo. Mmm... queda a criterio de los administradores.

Modificar /etc/motd

Message of the day es lo que se muestra a todos los usuario cada vez que inician sesión en el sistema antes de que se inicie la shell. Sería conveniente que los usuarios vean un mensaje similar a este:

Este sistema es para el uso exclusivo de usuarios autorizados, por lo que las personas que lo utilicen estarán sujetos al monitoreo de todas sus actividades en el mismo. Cualquier persona que utilice este sistema permite expresamente tal monitoreo y debe estar consciente de que si este revelara una posible actividad ilicita, el personal de sistemas proporcionara la evidencia del monitoreo al personal de seguridad, con el fin de emprender las acciones civiles y/o legales que correspondan.

Así, cada persona que acceda es advertida sobre los términos y condiciones para operar en el sistema.

Modificar /etc/issue

Este fichero de texto plano contiene información del sistema operativo instalado, se muestra en la pantalla de inicio de sesión y acepta ciertos comandos. En el caso de Debian, contiene Debian GNU/Linux 8 \n \l, donde \n y \l son comandos que insertan el hostname y el nombre de la tty actual, respectivamente. También se puede insertar la arquitectura de la máquina, nombre de dominio, versión del kernel...

Si algún intruso obtiene esa información valiosa, puede recurrir a exploits o código malicioso y ejecutarlo contra nuestro sistema.

Revisar servicios habilitados

Si el servidor cumplirá la función de border router... ¿para qué está instalado el Apache? Es importante tener control sobres los servicios habilitados. Es posible saber cuáles son a través de la shell:

$ systemctl list-unit-files | awk '$2 =="enabled" {print $0}'

Si alguno de ellos no corresponde estar habilitado, podemos deshabilitarlo fácilmente con este comando:

# systemctl disable <service-name>

Respaldos

Es imperdonable no tener un backup del servidor, sea cual sea la función que cumpla. Ante cualquier desastre se podrá hacer una recuperación íntegra del sistema y de esa manera, sólo el tiempo que demandará realizar esa recuperación, afectará al negocio de la organización.

¿Qué herramientas usar? Depende de lo que se quiera respaldar: máquinas virtuales, sistema, ficheros, imágenes, datos de usuario... Por ejemplo, para respaldas máquinas virtuales en KVM, se toman snapshots de esas máquinas, luego son convertida y, finalmente, copiadas en un storage usando rsync+ssh.

Lo importante, independiente de la herramienta, es definir la política de respaldos, que puede ser diferencial, incremental o total, y un calendario para generarlos de manera automatizada. Y una vez realizados esos respaldos, comprobar que son funcionales ;)

Administración remota del servidor

Lo más usual es utilizar SSH. Pero no hay que olvidarse de realizar una configuración adecuada del mismo luego de su instalación. Escribí una entrada en mi blog dedicada a ello.

Mi preferencia es utilizar una conexión VPN, siempre. Y a partir de allí, conectarse a un SSH, RDP, SFTP, VNC o lo que sea.

Contorlar la performance del servidor

Herramientas como top, free, lsof, iftop, df, tcpdump, ayudan a controlar y monitorear la utilización de recursos del servidor. Es importante conocerlas y manejarlas para cuando se deba hacer troubleshooting.

Limitar el acceso a las tty al usuario root

El usuario root tiene acceso a todas las tty. Para deshabilitarlo, se debe configurar el fichero /etc/securetty, comentando en qué terminales no se quiere que el root inicie sesión.

Si se necesita ejecutar comandos con permisos de root, se inicia sesión con un usuario común y luego se escalan privilegios.
El fichero se vería así:
.............................

# Virtual consoles
#tty1
#tty2
#tty3
#tty4
#tty5
#tty6
#tty7
#tty8
#tty9
#tty10
#tty11

.............................

En el mismo fichero también se listan terminales que pueden ser accedidas vía UART (puerto serial), dispositivos MUX, etc. Ese hardware lo más probable es que no se disponga, por lo que esas líneas pueden ser eliminadas del archivo.

Refinar los accesos

El módulo PAM es el que se encarga de gestionar todo lo relacionado a accesos. Lee el fichero /etc/security/access.conf y otros que pueden ser creados por el usuario para accesos más granulares, por ejemplo uno específico para protocolo SSH.

Allí se especifican combinaciones del tipo (user/group, host), (user/group, network/netmask) o (user/group, tty) y define si un login es aceptado o no.

Cuando un usuario se loguea, este archivo es escaneado y se busca la primer regla que coincida con alguna de las especificaciones de acceso.

Por ejemplo:

# root no tiene acceso desde ninguna parte
- : root : ALL

# verovand sólo accede desde la net/mask
+ : verovand : 192.168.0.0/24

Limitar acceso a los recursos

/etc/security/limits.conf es otro fichero leído por el módulo PAM en el que se puede limitar el acceso a los recursos del sistema por parte utilizados por usuarios o grupos de usuarios.

Por ejemplo, el fichero podría lucir de la siguiente forma:

verovan - maxlogin 2
* * nproc 100

Configurar el autologout de los usuarios

Es posible cerrar la sesión de un usuario luego de cierto tiempo de inactividad en el sistema. Para conseguirlo, dependiendo si se quiere que tenga efecto en shells interactivas o en interactivas y no interactivas, se debe incluir la variable de entorno TMOUT en el fichero /etc/profile o /etc/bash.bashrc, respectivamente.

TMOUT=360 #después de 6 minutos cierra la sesión

Útil para terminar las sesiones abiertas que quedaron olvidadas en el sistema...

Enjaular (chroot)

Es una técnica para configurar un directorio como si fuese la raiz, de manera que no es posible acceder a ficheros fuera del mismo, tampoco ejecutar comandos de shell, hacer uso de librerías, etc.

Es muy útil cuando se tiene que hacer manetenimieto del sistema (reparar GRUB, desistalar paquetes, actualizar un paquete, etc.). También para dar acceso a través de la shell vía FTP o SSH a usuarios.

Correcto uso de sudo

Al comando sudo hay que emplearlo con cuidado. Si bien es práctico y sencillo de utilizar, ya que no requerimos de la contraseña de root para ejecutar un comando, es peligroso por el motivo que se mencionó recién.

sudo no reemplaza a su:

- el primero permite obtener los permisos de superusuario (u otro usuario) y ejecutar un comando. Las pólizas de seguridad definen con qué privilegios, si existen, un usuario puede ejecutar sudo y se especifican en el fichero /etc/sudoers.

- el segundo permite convertirse en otro usuario, incluído root. Para ello se requiere saber su contraseña.

Si sólo se tiene acceso privilegiado a través de sudo y "se rompe sudo", se estará en modo single user. Por lo tanto, se debe setear un password para root y asegurarse que puede utilizarse ;)

No se debería emplear sudo para editar archivos o para evitar loguearse como otro como usuario, por ejemplo. Para la primera situación se recurre a grupos de usuarios y permisos específicos para tal tarea.

Editar el fichero /etc/sudoers no es tarea sencilla, pero es la manera de definir las políticas para permitir a ciertos usuarios ejecutar ciertos comandos en un host determinado.

Control de acceso

- Manejo de DAC (Discretionary Access Control): a través de los comandos chmod y chattr(lsattr) para modificar los permisos atributos de un archivo, respectivamente.

- Manejo de ACL (Access Control List): la mayoría de los usuarios utiliza la manera tradicional de asignación de permisos sobre un archivo a través del comando chmod. Para un control más granular se utilizan los comandos getfacl y setfacl.

- Sticky bit (se aplica a directorios): para prevenir que un usuario borre un fichero del que no es propietario y que se encuentra dentro de un directorio sobre el que tiene permisos de escritura.

- SUID,SGID (se aplica a ficheros): para permitir la ejecución de un binario con los permisos del propietario o del grupo ¡Manejarlo con mucho cuidado!

-Revisar directorios con permisos especiales

[root@server ~]# find / -type f -perm 1000 -ls

[root@server ~]# find / -perm -o=w ! -type l -ls

Gestión de logs:

Mantener logs del sistema o de un servicio es importantísimo.

Es posible gestionar los mismos con logrotate, que es un proceso que se encarga de rotar, comprimir, eliminar y enviar por mail los logs. Se ejecuta diariamente como una tarea croneada.

Otra opción disponer de un servidor centralizado como ZABBIX para monitorear y analizar logs.

Usar HIDS (Tripwire)

Tripwire es un IDS basado en host que monitorea los cambios que se producen en diferentes puntos del filesystem y almacena todas esas ocurrencias detectadas en su base de datos. La herramienta genera un reporte que se puede enviar vía mail.

Es válido pensar de qué serviría si el sistema ya fue comprometido... bueno, es demasiado útil, ya que al momento de auditar se tiene información sobre qué ocurrió, qué parte del sistema de archivos se vio afectada, etc.

Usar keyloggers
A través de herramientas como Snoopy se puede mantener en archivos de log el registro de los comandos que un usuario ejecuta.
Al igual que Tripwire, provee al administrador una manera controlar y saber qué ocurre en el sistema y saber quién hace qué cosas.

Auditar el servidor

Lynis es una herramienta muy interesante para auditoría de sistemas Linux. Básicamente audita el software instalado para buscar problemas de seguridad. Junto a esta información también buscará información general del sistema, paquetes instalados y errores de configuración. En el informe que genera, además incluye otros aspectos, como los relacionados con networking, soporte para virtualización, firewall, kernel, base de datos, etc.

Es muy sencilla de instalar y utilizar.

Junto a la información relacionada con la seguridad también buscará información general del sistema, los paquetes instalados y los errores de configuración. También nos mostrará información sobre diferentes aspectos extra, como boot loaders, networking, virtualización, procesos zombie, criptografía, impresoras, firewalls, kernel, bases de datos, etc. - See more at: https://www.redeszone.net/gnu-linux/auditoria-completa-de-tu-distribucion-linux-con-lynis/#sthash.nDS5e340.dpuf

unto a la información relacionada con la seguridad también buscará información general del sistema, los paquetes instalados y los errores de configuración. También nos mostrará información sobre diferentes aspectos extra, como boot loaders, networking, virtualización, procesos zombie, criptografía, impresoras, firewalls, kernel, bases de datos, etc. - See more at: https://www.redeszone.net/gnu-linux/auditoria-completa-de-tu-distribucion-linux-con-lynis/#sthash.nDS5e340.dpuf

Configurar de manera segura los servicios

Es fundamental no dejar la configuración por defecto de ningún servicio. Además de eso hay que mantenerlos actualizados.

Se debe estar pendiente de la lista CVE (Common Vulnerabilities and Exposures) y revisarla periódicamente.

Tunning the kernel
Se modifica el valor de ciertas variables para:
Ignorar todos los paquetes echo:

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

Ignorar todos los mensajes broadcast:

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Evitar ataques ICMP redirect:

echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

Evitar ataques SYN:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Si no se tiene soporte para IPv6, desactivarlo.

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

Estas configuraciones no son persistentes, es decir que cuando el sistema se reinicie, las variables tomarán sus valores por defecto. Para que sobrevivan el reinicio, se debe editar el fichero /etc/sysctl.conf, en donde se representan cada una de ellas separadas por puntos en vez de barra inclinada.

Configurar el firewall (iptables)

La política de firewall por defecto de la mayoría de los sistemas Linux es ACCEPT para las cadenas INPUT, OUTPUT y FORWARD, cuando debería ser DROP por defecto. A partir de allí se crean las reglas adecuadas dependiendo de la función que el servidor cumpla.

Bueno, el post se hizo largo. Cualquier aporte es bienvenido.

Las herramientas que mencioné no son las únicas.

Para cada uno de los comandos mencionados, se recomienda consultar el man correspondiente.

Saludos..!

Mastering Mikrotik

noreply@blogger.com (Unknown) — Tue, 14 Feb 2017 23:28:00 -0200

Buenas noches, bloggeros.

Esta entrada quiero dedicarla, como puede apreciarse en el título de la misma, a Mikrotik y sus routers.

Mikrotik es una compaía que fabrica productos, tanto de software como harware, para conectividad de redes. Los más populares son Mikrotik RouterOS (basado en el kernel de Linux 3.3.5) y Mikrotik RouterBoard.

Muchos dicen que Mikrotik es para dummies... mi opinión es totalmente la opuesta. De acuerdo a mi experiencia con el hardware Mtk, pude comprobar que son equipos robustos, con buena capacidad de procesamiento, sencillos de configurar y con muchísimas funcionalidades y tools para administración.

El setup básico lo pueden encontrar en internet. Realmente es muy fácil conectarlo y que empiece a trabajar como router. Obviamente podemos realizar configuraciones avanzadas de red si fuese necesario: VLANs, túneles EoIP, cualquier configuración de firewall, IPSec y un largo etcétera.

Mi intención es compartir un breve resúmen de algunas utilidades de estos equipos que muchas veces no se tienen en cuenta, pero que son importantes al momento de hacer tests de conectividad, comprobar que los enlaces funcionen correctamente, sniffear las conexiones, entre otras cosas.

Bueno, vamos a ello... comentaré de qué se tratan sólo algunas de estas utilidades (las que me parecieron más relevantes)

TOOLS

BT Server: es un servidor que sirve para realizar test de ancho de bandas con otro dispositivo Mikrotik.
Bandwidth test: muy útil para chequear el ancho de banda siempre y cuando se realizce contra otro Mikrotik. En el Mikrotik remoto debe estar configurado el BT Server.
Torch: se utiliza para monitorear el tráfico de red que circula a través de alguna de las interfaces del router. Es posible filtrar por MAC, protocolo, VLAN ID, etc.
Graphs: simplemente genera gráficas relativas a los recursos que utiliza el router, que son CPU, memoria, disco y red. Es importante tener en cuenta que estas gráficas son accedidas vía HTTP desde cualquier equipo que tenga acceso al router y no pueden ser protegidas con user y pass. Si el router está expuesto a internet, se debe configurar las gráficas para que sólo sean vistas desde la red local.
Sniffer: es el análogo a Wireshark de Mikrotik. Analiza los paquetes que van y vienen a través del router. Una cosa muy interesante es que es posible enviar las capturas realizadas a un streaming server, que puede ser un Wireshark, para un análisis con mayor detenimiento.
Profiler: permite saber qué procesos están consumiendo ciclos de CPU.
IP Scan: para hacer una comparación, es el NMap de Mikrotik. Permite realizar un escaneo de red sobre una interface determinada.
Netwatch: monitorea si un host está activo y, adicionalmente, permite la ejecución de scripts en caso de que dicho host esté "caído".
Traceroute: no hay mucho para explicar. Sólo que se utiliza para conocer qué caminos recorre un paquete (a través de qué routers circula hasta llegar a destino)
Traffic monitor: cada vez que una interfaz haya superado cierto umbral de transmisión ejecuta un script.

SYSTEM

Logging: genera logs del equipo. Se los almacena en el disco del propio router o en uno externo.
Scripts: se crean allí los scripts que se usan en el planificador de tareas, netwatch u otros.
Scheduler: es el cron/Task scheduler de Mikrotik. Con el ejecutamos los scripts a una hora determinada, de un día determinado bajo ciertas condiciones.
Watchdog: es el encargado de reiiniciar el equipo en caso de que ocurra un kernel panic o que el sistema se encuentre bloqueado.
Packages: es el gestor de paquetes que contienen diferentes features. Son desarrollados únicamente por Mikrotik.

Muchas de las opciones que se ven en la sección SYSTEM no son configurables.
Las capturas de pantalla son del panel de un RouterBoard 951, versión 6.30.4.

No olviden consultar la Wiki: http://wiki.mikrotik.com/wiki/Main_Page

Saludos... y happy config!

Comunidad LinuxChix Argentina!

noreply@blogger.com (Unknown) — Thu, 9 Feb 2017 23:38:00 -0200

Buenas noches, bloggeros.

En esta entrada es mi intención invitarlos a sumarse, a quienes no la conocen obviamente, a la comunidad LinuxChix Argentina.

Tal como lo dice su sitio oficial, LinuxChix Argenitina "somos un grupo de mujeres y hombres con diferentes perfiles dentro del ámbito de la tecnología en Argentina. Developers, admins, operators, estudiantes... ", que tiene por objetivo "[..] reunir mujeres que se encuentren trabajando con tecnologías libres" en donde intentan "[..] promover que más mujeres de diferentes ámbitos (relacionados con la tecnología) se involucren en este campo".

Conocí a este grupo por pura casualidad, dado que una de las co-fundadoras brindó una charla en la PyCon Argentina el año pasado. Si bien no pude ir a la conferencia, a través de la web conocí al grupo que es muy copado y tiene muchas ideas y, lo más importante, las han podido materializar con charlas, meetups y eventos.

Las mujeres dentro la tecnología hemos sido siempre parte de un grupo minoritario, dado que siempre esta área ha sido vinculada como masculina y en la que solamente los hombres pueden desempeñarse con éxito. Es sumamente importante entender que estas ideas han quedado en el pasado, pero que aín siguen vigentes y que es necesario un cambio cultural. Esta iniciativa, que dentro de poco cumplirá dos años, es un claro ejemplo de esto, por lo que tanto hombres como mujeres debemos nutrirla y empujarla para que siga adelante y en buen curso.

Me he sumado hace poco tiempo y quisiera que quienes lean esta resumidísima entrada de blog, también acompañen para que LinuxChix Argentina siga creciendo.

Si bien físicamente las reuniones se realizan en CABA y para quienes estamos lejos no podemos participar, nos llama para que desde nuestro lugar de residencia también llevemos adelante propuestas similares :)

En freenode pueden encontrar el canal #linuxchixar.

Saludos... y happy config!

Vulnerabilidad 0Day SMB3

noreply@blogger.com (Unknown) — Mon, 6 Feb 2017 14:51:00 -0200

Buenos días, bloggeros.

En esta publicación quiero compartirles la PoC para explotar una vulnerabilidad en SMB3 de Microsoft Windows.

Ya fue reportada y estamos esperando que prontamente se publique el parche correspondiente.

¿Qué es SMB y cómo funciona?

El Server Message Block (SMB) Protocol es un protocolo de uso compartido de archivos de red. El conjunto de paquetes de mensajes que define una determinada versión del protocolo se llama un dialecto. El Common Internet File System (CIFS) Protocolo es un dialecto de SMB. Tanto SMB y CIFS también están disponibles en VMS, varias versiones de Unix, y otros sistemas operativos.

Para tener en cuenta con las distintas versiones que hay en el mercado de acuerdo a nuestro sistema operativo:

CIFS – La versión antigua de SMB que era parte de Microsoft Windows NT 4.0 en 1996. SMB1 reemplaza esta versión.
SMB 1.0 (o SMB1) – La versión utilizada en Windows 2000, Windows XP, Windows Server 2003 y Windows Server 2003 R2
SMB 2.0 (o SMB2) – La versión utilizada en Windows Vista (SP1 o posterior) y Windows Server 2008
SMB 2.1 (o SMB2.1) – La versión utilizada en Windows 7 y Windows Server 2008 R2 SMB 3.0 (o SMB3) – La versión utilizada en Windows 8 y Windows Server 2012
SMB 3.02 (o SMB3) – La versión utilizada en Windows 8.1 y Windows Server 2012 R2

Una conexión simple con un servidor SMB consta de:

Establecer una conexión virtual.
Negociar el protocolo.
Definir parámetros de sesión.
Iniciar el Tree Connection hacia el recurso.

El problema surge luego de del mensaje Tree Connect Request, donde el servidor responde con un mensaje Tree Connect Response que aparentemente está bien, pero que en realidad tiene un tamaño excesivo, donde la cabecera NetBios del paquete tiene fijados (intencionalmente) 1580B, los 64B del SMB2 header y, finalmente, el Three Connect Response Message de 8B.

Haciendo uso del script en Python publicado en https://github.com/lgandx/PoC , podemos montar un fake SMB server, hacer que un cliente con versiones de Windows 8 o superiores se conecten y generar una BSOD.

Proceso de conexión entre el cliente y el falso SMB.

Lo he probado con Windows10 y no pude explotarlo, pero sin con Windows Server 2012R2.

A divertirse!

Saludos... y happy config!

Webinar "Seguridad en WordPress"

noreply@blogger.com (Unknown) — Sat, 4 Feb 2017 18:10:00 -0200

Buenas tardes, bloggeros.

En mi primer publicación (algo demorada) del año 2017, quiero compartirles una excelente charla online brindada por Daniel Maldonado (AKA @elcodigok), en la que nos contó algunas buenas prácticas de seguridad para ser aplicadas en los proyectos WordPress. Fue una pequeña introducción al curso que dará próximamente en a través de la plataforma Aula25.

Daniel es autor de un libro titulado "Máxima seguridad en WordPress", publicado para la editorial 0xWord.

No dejen de ver el seminario.

Saludos. Y happy config..!

Nuevo intento de estafa por correo electrónico #phishing

noreply@blogger.com (Unknown) — Sun, 18 Dec 2016 20:54:00 -0200

Buenas tardes, bloggeros!

Hoy me sorprendí cuando al chequear mi casilla de correo, encuentro en mi Inbox un mail con remitente PAYPAL... Bueno, no recuerdo haber creado una cuenta en dicho servicio, pensé. Y mi primer pensamiento fue que este sería un intento de estafa, de esas que tanto circulan por internet.

Vamos a ver...

Por empezar podemos ver que el correo electrónico de quien envía el mail es sumamente sospechoso... Haciendo uso del comando dig para consultar información sobre el dominio, obtuve lo siguiente:

Y a través de Robtex consulté más info: https://www.robtex.com/?dns=mckeetours.com

Es curioso que quienes envían el mail (la gente de PayPal) utilicen los servidores de mail de Google, no? Nada tiene que ver con los servidores de mail que usa PayPal (para consultarlos se puede ejecutar el comando dig mx paypal.com).

Adicionalmente, geolocalicé el dominio: https://www.elhacker.net/geolocalizacion.html?host=mckeetours.com y realicé la consulta Whois correspondiente, y observé que el dominio está dado de alta desde GoDaddy: https://www.elhacker.net/whois.html?domain=mckeetours.com

Creo que todo esto no era necesario, pero es interesante ver el trabajo que invierten los estafadores para realizar estas campañas de pishing que aún hoy son una de las más utilizadas para el robo de información.

Por último, accedí al enlace que me proporcionaban para cambiar mi contraseña de mi supuesta cuenta de PayPal. Podemos ver que se hizo un fino trabajo para imitar la página de login original de PayPal... pero miren la URL!! Y no utilizan HTTPS!! Y también falsificaron la página principal... todo muy bien hecho para engañar...

Página principal de PayPal FALSA

Página principal de PayPal VERDADERA

Como pudimos apreciar, el trabajo detrás de esto es fino... y quienes no están al tanto de la existencia de estas técnicas de engaño son víctimas fáciles. No tengo dudas de que alguien ha accedido a esta página, ingresado información como correo electrónico y, más grave, datos de tarjetas de crédito.

Para quienes nos desempeñamos en el área informática, es importante concientizar a las personas que no tienen conocimientos sobre phishing, por ejemplo.

Saludos... y happy config!

Configurando un SSH seguro

noreply@blogger.com (Unknown) — Sun, 9 Oct 2016 02:45:00 -0300

Buenas noches, bloggeros.

Bueno, el título del post lo dice todo: todos usamos SSH para algo... por eso es importante tener una configuración apropiada, ya que dejar la configuración by default no es una buena idea.

Hay muchas herramientas que nos ayudan a mantener nuestro servidor SSH a salvo de alguna manera, pero si la configuración del servidor no es la correcta, no nos valdrá de mucho el fail2ban, por ejemplo.

Vamos a lo importante, el fichero /etc/ssh/ssh_config:

# What ports, IPs and protocols we listen for - Lo podemos cambiar
Port 6622
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel VERBOSE

# Authentication:
LoginGraceTime 30
# Tiempo que disponemos para iniciar la sesión antes de que nos desconecte el server
PermitRootLogin no
#I M P O R T A N T E
StrictModes yes
AllowUsers yousuario
# Usuario que puede loguearse

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

#Deshabilitar el servidor X vía SSH
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

MaxStartups 1
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

UsePAM yes
#
MaxAuthTries 3
#Cantidad maxima de intentos de logueo
ClientAliveInterval 300
AllowTcpforwarding no
DebianBanner no
#Ocultar la info de nuestro server si nos escanea nmap

Lo recomendable, sin embargo sería:

loguearnos utilizando clave pública/clave privada
indicar la IP desde la que vamos a loguearnos (no siempre es posible)
conectarnos al server a través de VPN

A veces debemos exponer nuestro servidor en internet, por lo que vamos a ser víctimas de bots intentando hacerse del server mediante ataque de fuerza bruta. Por eso fail2ban es una herramienta súmamente interesante que nos ayudará a mantener en lista negra, mediante iptables, a todas aquellas IP que hayan provocado intentos fallidos de conexión.

En Debian y derivados, pueden encontrar a fail2ban en los repositorios e instalarlo mediante el comando

apt-get install fail2ban

Se cambian algunas cositas del fichero /etc/fail2ban/jail.conf (esto sólo es una porción del fichero)

[DEFAULT]

ignoreip = 127.0.0.1/8

ignorecommand =

# "bantime" is the number of seconds that a host is banned.
bantime  = 25200

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime = 60
maxretry = 3

backend = polling

usedns = warn

destemail = root@localhost

sendername = Fail2Ban

sender = fail2ban@localhost

#
# ACTIONS
#

banaction = iptables-multiport

# email action. Since 0.8.1 upstream fail2ban uses sendmail
# MTA for the mailing. Change mta configuration parameter to mail
# if you want to revert to conventional 'mail'.
mta = sendmail

# Default protocol
protocol = tcp

# Specify chain where jumps would need to be added in iptables-* actions
chain = INPUT

#
# Action shortcuts. To be used to define action parameter

# The simplest action to take: ban only
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]

# ban & send an e-mail with whois report to the destemail.
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
              %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s", sendername="%(sendername)s"]

# ban & send an e-mail with whois report and relevant log lines
# to the destemail.
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
               %(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s", sendername="%(sendername)s"]

# Choose default action.  To change, just override value of 'action' with the
# interpolation to the chosen action shortcut (e.g.  action_mw, action_mwl, etc) in jail.local
# globally (section [DEFAULT]) or per specific section
action = %(action_)s

#
# JAILS
#

[ssh]

enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3

Y también en /etc/fail2ban/action.d/iptables-blocktype.conf

[INCLUDES]

after = iptables-blocktype.local

[Init]

# Option:  blocktype
# Note:    This is what the action does with rules. This can be any jump target
#          as per the iptables man page (section 8). Common values are DROP
#          REJECT, REJECT --reject-with icmp-port-unreachable
# Values:  STRING
#blocktype = REJECT --reject-with icmp-port-unreachable
blocktype = DROP

para que en vez de hacer un REJECT haga DROP sobre la IP banneada.

Otra capa de seguridad que podemos añadir al servicio es la autenticación de dos pasos y la integración de Latch.

Como lectura adicional, les dejo dos enlaces que me parecen sumamente interesantes relacionados con el tema de este post:

Espero que haya sido de utilidad. No obstante, siempre lo mejor es leer la docu oficial para ajustar la configuración de la mejor manera.

Saludos... y happy config.!