CategoríaGNU/Linux

Temas Referente a Linux

Balancear la carga manualmente (definir mas de un gateway)

La idea de balancear la carga manualmente es poder definir más de un gateway para distintos destinos, especificados por nosotros mismos. De esta manera, podremos tener dos o más salidas a internet y definir salidas hacia distintos rangos de direcciones ip.

multi gateway

Esto sirve de gran utilidad cuando nos conectamos a una red wifi que –por casualidad– llega hasta nuestro lugar de trabajo o nuestras casas e inocentemente queremos usarla. Por ejemplo, si tenemos un lugar de descargas, podemos dejar una máquina con una ruta estática que haga que cuando conecte a una IP x.x.x.x su salida a internet sea por el gateway predefinido por nosotros.
Para esto vamos a usar el comando route.

Seguir leyendo

Local root exploit en kernel 2.6.x (hasta la 2.6.29)

El Viernes pasado se anunciaron, en la lista de seguridad de debian, actualizaciones para el kernel, que solucionaba varias vulnerabilidades.

CVE-2009-0028

    Chris Evans discovered a situation in which a child process can
    send an arbitrary signal to its parent.

CVE-2009-0834

    Roland McGrath discovered an issue on amd64 kernels that allows
    local users to circumvent system call audit configurations which
    filter based on the syscall numbers or argument details.

CVE-2009-0835

    Roland McGrath discovered an issue on amd64 kernels with
    CONFIG_SECCOMP enabled. By making a specially crafted syscall,
    local users can bypass access restrictions.

CVE-2009-0859

    Jiri Olsa discovered that a local user can cause a denial of
    service (system hang) using a SHM_INFO shmctl call on kernels
    compiled with CONFIG_SHMEM disabled. This issue does not affect
    prebuilt Debian kernels.

CVE-2009-1046

    Mikulas Patocka reported an issue in the console subsystem that
    allows a local user to cause memory corruption by selecting a
    small number of 3-byte UTF-8 characters.

CVE-2009-1072

    Igor Zhbanov reported that nfsd was not properly dropping
    CAP_MKNOD, allowing users to create device nodes on file systems
    exported with root_squash.

CVE-2009-1184

    Dan Carpenter reported a coding issue in the selinux subsystem
    that allows local users to bypass certain networking checks when
    running with compat_net=1.

CVE-2009-1192

    Shaohua Li reported an issue in the AGP subsystem they may allow
    local users to read sensitive kernel memory due to a leak of
    uninitialized memory.

CVE-2009-1242

    Benjamin Gilbert reported a local denial of service vulnerability
    in the KVM VMX implementation that allows local users to trigger
    an oops.

CVE-2009-1265

    Thomas Pollet reported an overflow in the af_rose implementation
    that allows remote attackers to retrieve uninitialized kernel
    memory that may contain sensitive data.

CVE-2009-1337

    Oleg Nesterov discovered an issue in the exit_notify function that
    allows local users to send an arbitrary signal to a process by
    running a program that modifies the exit_signal field and then
    uses an exec system call to launch a setuid application.

CVE-2009-1338

    Daniel Hokka Zakrisson discovered that a kill(-1) is permitted to
    reach processes outside of the current process namespace.

CVE-2009-1439

    Pavan Naregundi reported an issue in the CIFS filesystem code that
    allows remote users to overwrite memory via a long
    nativeFileSystem field in a Tree Connect response during mount.

Se publicaron dos exploits para explotar vulnerabildades de escalacion de provilegios local. Estos exploits se aprovechan de la funcion ptrace_attach() para ejecutar un codigo arbitrario que nos permita ejecutar una shell del tipo /bin/sh como root.
El primer exploit es el shoryuken, lo probé en distintas versiones del kernel de debian y archlinux, pudiendo ser explotada solo la version 2.6.26-1-686 de Debian 5.0, de forma aleatoria, es decir, hay veces que ejecuto el exploit y funciona y otras veces no. El segundo script fue probado por su autor en la version del kernel 2.6.29rc1 de Gentoo.
Estos exploits funcionan bajo situaciones especificas y no todos los sistemas son vulnerables.

Saporm: Simple abstraccion de bases de datos

Hace un par de dias venia en el bus hacia mi casa y se me ocurrio una idea. Muchos pensara que ya existe esto que se me ocurrio, que existen frameworks, etc. Pero mi idea es hacer algo mas simple aun, se me ocurrio la idea de desarrollar un ORM (Object Relational Mapping) simple, que me permita de manera sencilla abstraer la base de datos para poder trabajarla como objeto. Mientras veina en el bus, pensaba el modelo logico para llevar acabo esta idea, luego de unos dias por fin he podido empezar a codificar lo que será desde ahora en adelante: Saporm. Como Hibernate para Java o Doctrine para PHP, la idea de este ORM es hacer las cosas aun mas faciles y mi idea, principalmente, es orientarla a proyectos pequeños y no a enterprise.

La idea es que este ORM/Framework haga todas las tareas de consultas y accesos a la base de datos de manera mas simple, por ejemplo, en Saporm, para que el framework sea capaz de abstraer la base de datos solo hay que crear una clase con los atributos correspondientes, segun los campos que tenga la tabla de la base de datos.
Por ejemplo, tenemos dentro del directorio “model” la siguiente clase:
(Usuarios.class.php)

  1. < ?php
  2. class Usuarios extends Core{
  3.    /* Variables necesarias por el ORM, es necesario que se declaren */
  4.    public $table_name;
  5.    public $socket;
  6.  
  7.    /* Variables del usuario */
  8.    public $id;
  9.    public $username;
  10.    public $password;
  11. }
  12. ?>

Saporm se encargará, automaticamente, de mapear la tabla “Usuarios” con sus atributos “id, username y password” y nos permitirá trabajarla como si de un objeto se tratara. La herramienta nos creara un objeto con el nombre Usuarios que contará con varios métodos y atributos, como por ejemplo:

$usuarios->search();
$usuarios->loadData();
$usuarios->select();
$usuarios->query();
$usuarios->insert();
$usuarios->update();

Seguir leyendo

Sistemas de ficheros: ext3 o XFS?

El escenario era el siguiente:
Servidor Intel Xeon con cuatro núcleos de 2Ghz cada uno, 8Gb de ram y un arreglo de discos SCSI en Raid5 (300Gb). La funcionalidad del servidor es ser un host de máquinas virtuales. El diléma era qué filesystem usar, estába entre ext3 y XFS entonces me puse a googlear y encontre varios benchmarks y comentarios interesante al respecto, donde se comparaban esos dos o más sistemas de ficheros. Mis necesidades eran encontrar un sistema de ficheros que sea rápido y que trabaje bien con ficheros de gran tamaño (>=1Gb).
Navegando y navegando, me encontré con un benchmark en el sitio debian-administrator que me ayudó en parte a decidir lo que debía hacer.
En dicho benchmark se analizaron los siguientes puntos:

* Operations on a large file (ISO image, 700MB) Copy ISO from a second disk to the test disk
* Recopy ISO in another location on the test disk
* Remove both copies of ISO

* Operations on a file tree (7500 files, 900 directories, 1.9GB) Copy file tree from a second disk to the test disk
* Recopy file tree in another location on the test disk
* Remove both copies of file tree

* Operations into the file tree List recursively all contents of the file tree and save it on the test disk
* Find files matching a specific wildcard into the file tree

* Operations on the file system Creation of the filesystem (mkfs) (all FS were created with default values)
* Mount filesystem
* Umount filesystem

Según ese artículo, el fs que mejor trabaja con ficheros de gran tamaño es xfs. Se hicieron dos tipos de pruebas, comparando jfs, xfs, ext3 y reiserfs. En la primera ganó xfs y ext3, en la segunda xfs y jfs.

The initial copy of the large file took longer on Ext3 (38.2 secs) and ReiserFS (41.8) when compared to JFS and XFS (35.1 and 34.8). The recopy on the same disk advantaged the XFS (33.1 secs), when compared to other FS (Ext3 = 37.3, JFS = 39.4, ReiserFS = 43.9). The ISO removal was about 100 times faster on JFS and XFS (0.02 sec for both), compared to 1.5 sec for ReiserFS and 2.5 sec for Ext3! All FS took comparable amounts of CPU to copy (between 46 and 51%) and to recopy ISO (between 38% to 50%). The ReiserFS used 49% of CPU to remove ISO, when other FS used about 10%. There was a clear trend of JFS to use less CPU than any other FS (about 5 to 10% less). The number of minor page faults was quite similar between FS (ranging from 600 – XFS to 661 – ReiserFS).
Conclusion : For quick operations on large files, choose JFS or XFS. If you need to minimize CPU usage, prefer JFS.
Operations on a file tree (7500 files, 900 directories, 1.9GB)
[…]
Conclusion : For quick operations on large file tree, choose Ext3 or XFS. Benchmarks from other authors have supported the use of ReiserFS for operations on large number of small files. However, the present results on a tree comprising thousands of files of various size (10KB to 5MB) suggest than Ext3 or XFS may be more appropriate for real-world file server operations. Even if JFS minimize CPU usage, it should be noted that this FS comes with significantly higher latency for large file tree operations.

Todo indicaba que debia usar XFS, pero la realidad era otra.
Seguir leyendo

Tunear MySQL o cómo aumentar el rendimiento de tu servidor

Buscando como mejorar el rendimiento de un servidor mysql encontre un script en perl que realiza una serie de pruebas en nuestras bases de datos y finalmente nos muestra un resultado de esos test de memoria, consulta, “velocidad”, rendimiento, etc. Y nos da algunos tips para poder mejorar la configuracion del mysql y llegar a un rendimiento mas optimo.

Caracteristicas del mysqltuner:

* Memory Usage: Calculates MySQL memory usage at max load and makes recommendations for increasing or decreasing the MySQL memory footprint. Per-thread and server-wide buffer data is calculated
separately for an accurate snapshot of the server?s configuration.
* Slow Queries: Reviews the amount of slow queries relative to the total queries. Slow query time limits are also analyzed and recommendations are made.
* Connections: Current and historical connection counts are reviewed.
* Key Buffer: Takes configuration data and compares it to the actual indexes found in MyISAM tables. Key cache hit rates are calculated and variable adjustments are suggested.
* Query Cache: Query cache hit rates and usage percentages are used to make recommendations for the query cache configuration variables.
* Sorting & Joins: Per-thread buffers that affect sorts and joins are reviewed along with the statistics from the queries run against the server.
* Temporary Tables: Variable recommendations are made to reduce temporary tables that are written to the disk.
* Table Cache: Compares total tables opened to the currently open tables. Calculates the table cache hit rate in order to make suggestions.
* Open Files: Determines if the server will approach or run into the open file limit set by the operating system or the MySQL server itself.
* Table Locks: Finds table locking that forces queries to wait and makes suggestions for reducing locks that require a wait.
* Thread Cache: Calculates how many times MySQL must create a new thread to respond to a query.
* Aborted Connections: Finds applications that are not closing connections to MySQL properly.
* Read/Write Ratios: Calculates the percentage of read and write operations on your MySQL installation.

Seguir leyendo

DomainKeys (DK) y DomainKeys Identified Mail (DKIM)

DomainKeys (DK) y DomainKeys Identified Mail (DKIM) son métodos de valicación de correo electrónico que permiten validar y firmar, mediante firma digital (clave pública y clave privada), los correos entrantes y salientes de nuestro servidor de correos. Esto permite que un dominio sea responsable por los correos que se envien a través de el para asegurarse que lleguen al inbox o que, de lo contrario, lleguen directo al junk.
Para validar la autenticidad de un remitente existen varias formas a nivel de dominio (dns) como es el SPF, Sender-ID, DK y DKIM.

Este último tiempo he estado trabajando con postfix validando los correos salientes para llegar al inbox de los servidores de correo más populares como Gmail, Yahoo! y Hotmail (msn, live, etc).
Estuve analizando las especificaciones RFC de cada protocolo (RFC4870 – DK; RFC4871 – DKIM), probandolas e implementandolas, llegando a distintas conclusiones. Básicamente, el diagrama de funcionalidad es el siguiente:

dk_graph

Seguir leyendo