iMasters

Recentemente, algumas pessoas começaram a se perguntar como Arakoon, nossa loja de chave-valor distribuída, lida com o drive no qual os dados são armazenados. Para ser mais claro, isso se resume à forma como Tokyo Cabinet (que usamos atualmente como implementação de banco de dados) envia solicitações de gravação para o kernel, e como ele processa essas informações mais tarde, após traduzir os pedidos de nível de sistema de arquivos em operações de escrita na camada do bloco.

É importante saber isso devido ao uso de drives SSD – pense em nivelamento de desgaste e outras questões vêm com esses dispositivos.

O rastreamento de como o aplicativo grava dados em um arquivo pode ser conseguido usando a ferramenta strace, buscando por chamadas write(2) e pwrite(2)  (embora isso não seja necessariamente suficiente: o aplicativo pode ser escrito em um arquivo usando mapeamentos de memória mmap(2)).

Entretanto, na maioria dos carregamentos, isso não corresponde à forma como os pedidos de bloco são enviados para o hardware: as gravações podem ser bufferizadas, reordenadas etc. O que desejamos é uma maneira de reunir informações de solicitações de gravação na camada do bloco do kernel.

No Linux, pode-se usar SystemTap (que possui algumas semelhanças com o DTrace em Solaris) para fazer um hook no kernel no tempo de execução e recolher estatísticas, ou muitas outras informações. Também é possível escrever um script que se liga aos pontos de rastreio ou chamadas de função, então processa a informação recebida.

Não vou entrar na instalação de SystemTap, uma vez que isso dependerá da distribuição que você está rodando. Note que você pode não precisar de acesso root para executar os scripts (você também nem deveria!): no meu sistema Fedora 16, tudo o que eu tinha que fazer era colocar o meu usuário nos grupos stapsys, stapusr e stapdev (embora eu não tenha certeza de que realmente preciso estar em todos aqueles…). Você vai precisar depurar arquivos de símbolos de seu kernel disponível em execução, entre outras coisas (na minha experiência de tentar executar um script em um sistema onde alguns pré-requisitos estão faltando, isso resultará na ferramenta stap dizendo o que você precisa).

Escrever scripts SystemTap às vezes requer algum conhecimento interno do kernel, para saber onde fazer o hook. Uma vez que quis reunir algumas estatísticas sobre chamadas de nível de bloco, eu sabia que tinha que procurar por chamadas no subsistema «bio», abreviação de “Block IO “. Por sorte, SystemTap vem com algumas combinações predefinidas de hooks, chamados de ‘tapsets’. Elas são armazenadas (no meu sistema, pelo menos) em /usr/share/systemtap/tapset. Um desses arquivos é chamado ioblock.stp, o que parece interessante. Já que eu estava com muita preguiça para procurar a documentação, abri o arquivo em um paginador e li por ele. O tap ioblock.request parecia interessante, o que dá acesso a um valor size. Depois de ler alguns exemplos de scripts SystemTap, eis o que eu criei:

global writes

probe ioblock.request {
    if(bio_rw_num(rw) == BIO_WRITE)
        writes[devname] <<< size
}

probe end {
    printf("\n")
    foreach([devname] in writes-) {
        printf("Device: %s\n", devname)
        println(@hist_log(writes[devname]))
    }
}

Executar isso usando a ferramenta stap, e fechar depois de um tempo (usando CTRL-C), fornece o seguinte resultado:

$ stap -v blockio.stp
Pass 1: parsed user script and 92 library script(s) using 210196virt/30852res/3136shr kb, in 140usr/20sys/251real ms.
Pass 2: analyzed script: 3 probe(s), 21 function(s), 2 embed(s), 2 global(s) using 452960virt/226472res/92556shr kb, in 1500usr/100sys/2541real ms.
Pass 3: translated to C into "/tmp/stapeJldxD/stap_e40cc31c16b7dd290dabd43749c577a4_12507_src.c" using 452960virt/226600res/92684shr kb, in 10usr/0sys/12real ms.
Pass 4: compiled C into "stap_e40cc31c16b7dd290dabd43749c577a4_12507.ko" in 1780usr/350sys/2595real ms.
Pass 5: starting run.
^C
Device: sda5
value |-------------------------------------------------- count
    0 |@@@@@@@@@@@@@@@                                    30
    1 |                                                    0
    2 |                                                    0
      ~
  256 |                                                    0
  512 |                                                    0
 1024 |                                                    1
 2048 |                                                    0
 4096 |@@@@@@@@@@@@@@@@@@@@@@@@@@@                        54
 8192 |@@@                                                 7
16384 |@                                                   3
32768 |                                                    0
65536 |                                                    0

Device: dm-2
value |-------------------------------------------------- count
    0 |@@                                                  5
    1 |                                                    0
    2 |                                                    0
      ~
  256 |                                                    0
  512 |                                                    0
 1024 |@                                                   2
 2048 |                                                    0
 4096 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@                      58
 8192 |@@@@@@@                                            14
16384 |@@@                                                 6
32768 |                                                    0
65536 |                                                    0

Device: dm-4
value |-------------------------------------------------- count
    0 |@                                                   2
    1 |                                                    0
    2 |                                                    0
      ~
  256 |                                                    0
  512 |                                                    0
 1024 |@                                                   2
 2048 |                                                    0
 4096 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@                      58
 8192 |@@@@@@@                                            14
16384 |@@@                                                 6
32768 |                                                    0
65536 |                                                    0

Device: dm-1
value |-------------------------------------------------- count
 1024 |                                                    0
 2048 |                                                    0
 4096 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 50
 8192 |                                                    0
16384 |                                                    0

Device: sda
value |-------------------------------------------------- count
 1024 |                                                   0
 2048 |                                                   0
 4096 |@@                                                 2
 8192 |                                                   0
16384 |                                                   0

Pass 5: run completed in 10usr/50sys/15274real ms.

Isso é um histograma de solicitações de gravação bio para todos os dispositivos de bloco no meu sistema, enquanto o script estava sendo executado. Caso veja um monte de pedidos menores do que o tamanho da página em um dispositivo SSD (isso depende do hardware), você pode querer dar uma olhada nos padrões de gravação do seu aplicativo (embora, mesmo assim, as coisas possam não ser tão ruins quanto parecem à primeira vista, pois o drive SSD poderia executar lotes, remapeamento e qualquer outra coisa internamente).

Observe que a saída do script exibido acima não retrata o comportamento de Arakoon ou Tokyo Cabinet: ela mostra uma sessão padrão de desktop, (rodando Google Chrome, Evolution, Empathy, Skype e mais alguns aplicativos), durante um período de tempo muito curto. O teste foi executado em um sistema Fedora 16 para laptop, contendo um hard drive spinning usando uma combinação de Ext4 e XFS em vários volumes LVM2 no kernel 3.2.7-1.fc16.x86_64.

***

Texto original de Nicolas Trangez, disponível em http://blog.incubaid.com/2012/03/06/tracing-block-device-write-request-sizes-in-linux-using-systemtap/

Esta é a última parte da série “Sequestro de chamadas de sistema Linux”. Até agora, nós criamos um módulo de kernel carregável simples que registra um dispositivo de caractere miscellaneous. Isso significa que nós temos tudo que precisamos para corrigir a tabela de chamadas do sistema. Quase tudo, para ser honesto. Nós ainda temos que preencher a função our_ioctl e acrescentar algumas declarações ao nosso arquivo de origem. Ao final deste artigo, seremos capazes de interceptar qualquer chamada de sistema em nosso sistema.

Tabela de chamada de sistema

A tabela de chamada de sistema é simplesmente uma área no espaço de memória do kernel que contém endereços de handlers de chamada do sistema. Na verdade, um número de chamada de sistema é um offset nessa tabela. Isso significa que quando chamamos sys_write (para ser mais preciso - quando libc chama sys_write) em um sistema de 32 bits e passa o número 4 em registo EAX antes de int 0x80, ele simplesmente diz ao kernel para ir para a tabela de chamada do sistema, obter o valor no offset 4 do endereço da tabela de chamada do sistema e chamar a função para a qual o endereço aponta. Pode ser o número 1 em RAX no caso de um sistema de 64 bits (e syscall em vez de int 0x80). Os números de chamada de sistema são definidos em arch/x86/include/asm/unistd_32.h e arch/x86/include/asm/unistd_64.h para plataformas de 32 e de 64 bits, respectivamente. Neste artigo, vamos lidar com chamada de sistema sys_open, que é o número 5 para sistemas de 32 bits e o número 2 para sistemas de 64 bits.

Devido ao fato de os kernels modernos não exportarem mais o símbolo sys_call_table, teremos de encontrar, nós mesmos, a sua localização na memória. Existem algumas maneiras "obscuras" de encontrar a localização sys_call_table de forma programática, mas elas podem ou não funcionar. Especialmente a forma como são escritas. Portanto, vamos usar a forma mais simples e mais segura - leia a sua localização a partir do arquivo /boot/System.map. Por razões de simplicidade, vamos apenas usar o grep e pegar o endereço. No meu computador, o comando grep "sys_call_table" /boot/System.map (você deve verificar o nome do arquivo no seu sistema, como no meu é /boot/System.map-2.6.38-11-generic) dá a saída "ffffffff816002e0 R sys_call_table". Adicionar a variável global unsigned long * sys_call_table = (unsigned long*) 0xYour_Address_Of_Sys_call_table.

Preparativos

Vamos começar, como de costume, fazendo novas inclusões ao nosso código. Desta vez, os arquivos de inclusão são:

#include <linux/highmem.h>
#include <asm/unistd.h>

O primeiro é necessário devido ao fato de que a tabela de chamada de sistema está localizada na área somente leitura da memória em kernels modernos, e teremos que modificar os atributos de proteção da página de memória que contêm o endereço da chamada de sistema que queremos interceptar. O segundo é autoexplicativo após o parágrafo anterior. Não vamos usar valores codificados para chamadas de sistema, em vez disso, vamos usar os valores definidos no header unistd.h.

Agora vamos definir dois valores, que seriam usados como argumento cmd para a função our_ioctl. Um vai nos dizer para corrigir a tabela, outro dirá para corrigi-la restaurando o valor original.

/* IOCTL commands */
#define IOCTL_PATCH_TABLE 0x00000001
#define IOCTL_FIX_table   0x00000004

Adicione mais uma variável global int is_set=0, que será utilizada como flag informando se a chamada do sistema real (0) ou personalizada (1) está em uso.

É importante salvar o endereço do sys_open original já que não vamos implementar integralmente o nosso, em vez disso, nossa função vai registrar informações sobre os argumentos de chamada e, em seguida, realizar a chamada (original) real. Portanto, nós definimos uma função ponteiro (para chamada original) e uma função (para chamadas personalizadas):

/* Pointer to the original sys_open */
   asmlinkage int (*real_open)(const char* __user, int, int);
   
/* Our replacement */
   asmlinkage int custom_open(const char* __user file_name, int flags, int mode)
   {
      printk("interceptor: open(\"%s\", %X, %X)\n", file_name,
                                                    flags, 
                                                    mode);
      return real_open(file_name, flags, mode);
   }

Você observou o atributo "asmlinkage". Bem, ele é, na verdade, uma definição para o atributo. Não vamos nos aprofundar dessa vez, vou apenas dizer que esse atributo informa ao compilador como ele deve passar argumentos para a função, uma vez que está sendo chamado de um código assembly. O macro "__user" significa que o argumento está no espaço do usuário e a função deve executar determinadas operações para copiar para o espaço do kernel quando necessário. Nós não precisamos disso, o que significa que podemos ignorá-lo por agora.

Outra função crucial é o conjunto que nos permitirá modificar os atributos de memória de proteção de página diretamente. Alguém pode dizer que o dele é arriscado, mas, na minha opinião, isso é menos arriscado que realmente fazer uma correção na tabela de chamada de sistema como ela é; em primeiro lugar, dependente da arquitetura, e sabemos que as arquiteturas não mudam drasticamente; em segundo, nós usamos as funções do kernel para isso.

/* Make the page writable */
   int make_rw(unsigned long address)
   {
      unsigned int level;
      pte_t *pte = lookup_address(address, &level);
      if(pte->pte &~ _PAGE_RW)
         pte->pte |= _PAGE_RW;
      return 0;
   }

   /* Make the page write protected */
   int make_ro(unsinged long address)
   {
      unsigned int level;
      pte_t *pte = lookup_address(address, &level);
      pte->pte = pte->pte &~ _PAGE_RW;
      return 0;
   }

pte_t significa typedef struct {unsigned long pte} pte_t e representa page table entry. Embora seja simplesmente um unsigned long, ele é declarado como struct, a fim de evitar o uso indevido de tipo.

pte_t * lookup_address (unsigned long address, unsigned int *level) é fornecido pelo kernel e executa todo o trabalho sujo para gente, além de retornar um ponteiro para page table entry que descreve a page que contém o endereço. Esta função aceita os seguintes argumentos:

address - o endereço na memória virtual;
level - ponteiro para valores inteiros sem assinatura que aceitam o nível do mapeamento.

Vamos ao que interessa

Estamos quase lá. A única coisa que resta é a implementação real da função our_ioctl. Adicione as seguintes linhas:

switch(cmd)
   {
      case IOCTL_PATCH_TABLE:
         make_rw((unsigned long)sys_call_table);
         real_open = (void*)*(sys_call_table + __NR_open);
         *(sys_call_table + __NR_open) = (unsigned long)custom_open;
         make_ro((unsigned long)sys_call_table);
         is_set=1;
         break;
      case IOCTL_FIX_TABLE:
         make_rw((unsigned long)sys_call_table);
         *(sys_call_table + __NR_open) = (unsigned long)real_open;
         make_ro((unsigned long)sys_call_table);
         is_set=0;
         break;
      default:
         printk("Ooops....\n");
         break;
   }

E estas linhas para a função cleanup_module:

if(is_set)
   {
      make_rw((unsigned long)sys_call_table);
      *(sys_call_table + __NR_open) = (unsigned long)real_open;
      make_ro((unsigned long)sys_call_table);
   }

O nosso módulo de interceptor está pronto. Bem, quase pronto, pois precisamos compilá-lo. Faça isso, como de costume - faça.

Teste

Finalmente temos o nosso módulo configurado e pronto para usar, mas temos que criar um aplicativo do "cliente" , o código que vai "conversar" com o nosso módulo e dizer a ele o que fazer. Felizmente, isso é muito mais simples do que o resto do trabalho que fizemos aqui. Crie um novo arquivo de origem e digite as seguintes linhas:

   #include <stdio.h>
   #include <sys/ioctl.h>
   #include <sys/types.h>
   #include <sys/stat.h>
   #include <fcntl.h>


   /* Define ioctl commands */
   #define IOCTL_PATCH_TABLE 0x00000001
   #define IOCTL_FIX_TABLE   0x00000004


   int main(void)
   {
      int device = open("/dev/interceptor", O_RDWR);
      ioctl(device, IOCTL_PATCH_TABLE);
      sleep(5);
      ioctl(device, IOCTL_FIX_TABLE);
      close(device);
      return 0;
   }

salve como s manager.c e compile-o com o gcc -o manager manager.c.

Carregue o módulo, execute ./manager e depois descarregue o módulo quando o manager sair. Se você emitir o comando dmesg | tail, se você vir linhas que contenham "interceptor: open (bla bla bla)", então você saberá que essas linhas foram produzidas pelo nosso handler.

Agora somos capazes de interceptar chamadas de sistema em kernels modernos, apesar do fato de que sys_call_table já não é exportado. Embora nós lidamos com estruturas de baixo nível, que normalmente só são usadas pelo kernel, este ainda é um método relativamente seguro, desde que seu módulo seja compilado com o kernel em execução.

Espero que este artigo tenha sido útil. Vejo vocês na próxima!

⁂

Texto original de Alexey Lyashko, disponível em http://syprog.blogspot.com.br/2011/10/hijack-linux-system-calls-part-iii.html

Esta é a última parte da série “Sequestro de chamadas de sistema Linux”. Até agora, nós criamos um módulo de kernel carregável simples que registra um dispositivo de caractere miscellaneous. Isso significa que nós temos tudo que precisamos para corrigir a tabela de chamadas do sistema. Quase tudo, para ser honesto. Nós ainda temos que preencher a função our_ioctl e acrescentar algumas declarações ao nosso arquivo de origem. Ao final deste artigo, seremos capazes de interceptar qualquer chamada de sistema em nosso sistema.

Tabela de chamada de sistema

A tabela de chamada de sistema é simplesmente uma área no espaço de memória do kernel que contém endereços de handlers de chamada do sistema. Na verdade, um número de chamada de sistema é um offset nessa tabela. Isso significa que quando chamamos sys_write (para ser mais preciso - quando libc chama sys_write) em um sistema de 32 bits e passa o número 4 em registo EAX antes de int 0x80, ele simplesmente diz ao kernel para ir para a tabela de chamada do sistema, obter o valor no offset 4 do endereço da tabela de chamada do sistema e chamar a função para a qual o endereço aponta. Pode ser o número 1 em RAX no caso de um sistema de 64 bits (e syscall em vez de int 0x80). Os números de chamada de sistema são definidos em arch/x86/include/asm/unistd_32.h e arch/x86/include/asm/unistd_64.h para plataformas de 32 e de 64 bits, respectivamente. Neste artigo, vamos lidar com chamada de sistema sys_open, que é o número 5 para sistemas de 32 bits e o número 2 para sistemas de 64 bits.

Devido ao fato de os kernels modernos não exportarem mais o símbolo sys_call_table, teremos de encontrar, nós mesmos, a sua localização na memória. Existem algumas maneiras "obscuras" de encontrar a localização sys_call_table de forma programática, mas elas podem ou não funcionar. Especialmente a forma como são escritas. Portanto, vamos usar a forma mais simples e mais segura - leia a sua localização a partir do arquivo /boot/System.map. Por razões de simplicidade, vamos apenas usar o grep e pegar o endereço. No meu computador, o comando grep "sys_call_table" /boot/System.map (você deve verificar o nome do arquivo no seu sistema, como no meu é /boot/System.map-2.6.38-11-generic) dá a saída "ffffffff816002e0 R sys_call_table". Adicionar a variável global unsigned long * sys_call_table = (unsigned long*) 0xYour_Address_Of_Sys_call_table.

Preparativos

Vamos começar, como de costume, fazendo novas inclusões ao nosso código. Desta vez, os arquivos de inclusão são:

#include <linux/highmem.h>
#include <asm/unistd.h>

O primeiro é necessário devido ao fato de que a tabela de chamada de sistema está localizada na área somente leitura da memória em kernels modernos, e teremos que modificar os atributos de proteção da página de memória que contêm o endereço da chamada de sistema que queremos interceptar. O segundo é autoexplicativo após o parágrafo anterior. Não vamos usar valores codificados para chamadas de sistema, em vez disso, vamos usar os valores definidos no header unistd.h.

Agora vamos definir dois valores, que seriam usados como argumento cmd para a função our_ioctl. Um vai nos dizer para corrigir a tabela, outro dirá para corrigi-la restaurando o valor original.

/* IOCTL commands */
#define IOCTL_PATCH_TABLE 0x00000001
#define IOCTL_FIX_table   0x00000004

Adicione mais uma variável global int is_set=0, que será utilizada como flag informando se a chamada do sistema real (0) ou personalizada (1) está em uso.

É importante salvar o endereço do sys_open original já que não vamos implementar integralmente o nosso, em vez disso, nossa função vai registrar informações sobre os argumentos de chamada e, em seguida, realizar a chamada (original) real. Portanto, nós definimos uma função ponteiro (para chamada original) e uma função (para chamadas personalizadas):

/* Pointer to the original sys_open */
   asmlinkage int (*real_open)(const char* __user, int, int);
   
/* Our replacement */
   asmlinkage int custom_open(const char* __user file_name, int flags, int mode)
   {
      printk("interceptor: open(\"%s\", %X, %X)\n", file_name,
                                                    flags, 
                                                    mode);
      return real_open(file_name, flags, mode);
   }

Você observou o atributo "asmlinkage". Bem, ele é, na verdade, uma definição para o atributo. Não vamos nos aprofundar dessa vez, vou apenas dizer que esse atributo informa ao compilador como ele deve passar argumentos para a função, uma vez que está sendo chamado de um código assembly. O macro "__user" significa que o argumento está no espaço do usuário e a função deve executar determinadas operações para copiar para o espaço do kernel quando necessário. Nós não precisamos disso, o que significa que podemos ignorá-lo por agora.

Outra função crucial é o conjunto que nos permitirá modificar os atributos de memória de proteção de página diretamente. Alguém pode dizer que o dele é arriscado, mas, na minha opinião, isso é menos arriscado que realmente fazer uma correção na tabela de chamada de sistema como ela é; em primeiro lugar, dependente da arquitetura, e sabemos que as arquiteturas não mudam drasticamente; em segundo, nós usamos as funções do kernel para isso.

/* Make the page writable */
   int make_rw(unsigned long address)
   {
      unsigned int level;
      pte_t *pte = lookup_address(address, &level);
      if(pte->pte &~ _PAGE_RW)
         pte->pte |= _PAGE_RW;
      return 0;
   }

   /* Make the page write protected */
   int make_ro(unsinged long address)
   {
      unsigned int level;
      pte_t *pte = lookup_address(address, &level);
      pte->pte = pte->pte &~ _PAGE_RW;
      return 0;
   }

pte_t significa typedef struct {unsigned long pte} pte_t e representa page table entry. Embora seja simplesmente um unsigned long, ele é declarado como struct, a fim de evitar o uso indevido de tipo.

pte_t * lookup_address (unsigned long address, unsigned int *level) é fornecido pelo kernel e executa todo o trabalho sujo para gente, além de retornar um ponteiro para page table entry que descreve a page que contém o endereço. Esta função aceita os seguintes argumentos:

address - o endereço na memória virtual;
level - ponteiro para valores inteiros sem assinatura que aceitam o nível do mapeamento.

Vamos ao que interessa

Estamos quase lá. A única coisa que resta é a implementação real da função our_ioctl. Adicione as seguintes linhas:

switch(cmd)
   {
      case IOCTL_PATCH_TABLE:
         make_rw((unsigned long)sys_call_table);
         real_open = (void*)*(sys_call_table + __NR_open);
         *(sys_call_table + __NR_open) = (unsigned long)custom_open;
         make_ro((unsigned long)sys_call_table);
         is_set=1;
         break;
      case IOCTL_FIX_TABLE:
         make_rw((unsigned long)sys_call_table);
         *(sys_call_table + __NR_open) = (unsigned long)real_open;
         make_ro((unsigned long)sys_call_table);
         is_set=0;
         break;
      default:
         printk("Ooops....\n");
         break;
   }

E estas linhas para a função cleanup_module:

if(is_set)
   {
      make_rw((unsigned long)sys_call_table);
      *(sys_call_table + __NR_open) = (unsigned long)real_open;
      make_ro((unsigned long)sys_call_table);
   }

O nosso módulo de interceptor está pronto. Bem, quase pronto, pois precisamos compilá-lo. Faça isso, como de costume - faça.

Teste

Finalmente temos o nosso módulo configurado e pronto para usar, mas temos que criar um aplicativo do "cliente" , o código que vai "conversar" com o nosso módulo e dizer a ele o que fazer. Felizmente, isso é muito mais simples do que o resto do trabalho que fizemos aqui. Crie um novo arquivo de origem e digite as seguintes linhas:

   #include <stdio.h>
   #include <sys/ioctl.h>
   #include <sys/types.h>
   #include <sys/stat.h>
   #include <fcntl.h>


   /* Define ioctl commands */
   #define IOCTL_PATCH_TABLE 0x00000001
   #define IOCTL_FIX_TABLE   0x00000004


   int main(void)
   {
      int device = open("/dev/interceptor", O_RDWR);
      ioctl(device, IOCTL_PATCH_TABLE);
      sleep(5);
      ioctl(device, IOCTL_FIX_TABLE);
      close(device);
      return 0;
   }

salve como s manager.c e compile-o com o gcc -o manager manager.c.

Carregue o módulo, execute ./manager e depois descarregue o módulo quando o manager sair. Se você emitir o comando dmesg | tail, se você vir linhas que contenham "interceptor: open (bla bla bla)", então você saberá que essas linhas foram produzidas pelo nosso handler.

Agora somos capazes de interceptar chamadas de sistema em kernels modernos, apesar do fato de que sys_call_table já não é exportado. Embora nós lidamos com estruturas de baixo nível, que normalmente só são usadas pelo kernel, este ainda é um método relativamente seguro, desde que seu módulo seja compilado com o kernel em execução.

Espero que este artigo tenha sido útil. Vejo vocês na próxima!

⁂

Texto original de Alexey Lyashko, disponível em http://syprog.blogspot.com.br/2011/10/hijack-linux-system-calls-part-iii.html

Nós todos sabemos que os drivers de dispositivo são as mãos do sistema operacional que tornam possível para o kernel lidar com hardware. Sabemos também que existem dois tipos de dispositivos - character e block, dependendo da forma como eles lidam com transmissões de dados, mas o que dispositivo "miscellaneous" significa? Para colocar de uma maneira simples - ele significa que ele significa. Por um lado, isso pode ser um driver que lida com hardware simples; por outro, é a forma como o Linux nos permite criar dispositivos virtuais, como uma das maneiras de se comunicar com os módulos do kernel, que é exatamente o que precisamos para capturar chamadas do sistema Linux.

Neste artigo, vamos criar um dispositivo simples de caractere virtual, que será usado por um processo de espaço do usuário para instruir o nosso módulo do kernel se ele deve sequestrar ou restaurar determinada chamada de sistema. Esse dispositivo virtual será controlado com a função ioctl. Para simplificar, eu decidi não adicionar read/write handlers a esse dispositivo, pois não é realmente necessário para o que estamos prestes a fazer. Embora seja um recurso bom de ter.

Diversos dispositivos são representados com struct miscdevice, que é declarado em /include/linux/miscdevice.h como

struct miscdevice
   {
      int minor;
      const char *name;
      const struct file_operations *fops;
      struct list_head list;
      struct device *parent;
      struct device *this_device;
      const char *nodename;
      mode_t mode;
   };

Bem grande, hein? No entanto, só devemos cuidar dos três primeiros membros da estrutura:

minor representa o menor número do dispositivo. É preferível defini-lo como
MISC_DYNAMIC_MINOR (pelo menos para o nosso módulo) a menos que você precise que algum
número específico seja usado.
name é o nome do nosso dispositivo que deve aparecer no sistema de arquivos /dev
struct file_operations é um conjunto de ponteiros para implementações correspondentes de funções IO
e um ponteiro para o módulo proprietário.
Essa estrutura é muito grande para ser apresentada aqui, mas você pode encontrá-la em /include/linux/fs.h

Então, antes de tudo, adicione outro arquivo de inclusão ao seu código (que já escrevi no artigo anterior), com

#include <linux/miscdevice.h>

Em seguida, devemos adicionar handlers personalizados para funções e variáveis globais em que estejamos interessados, ou seja, open, release, ioctl e a variável in_use.

/* We will set this variable to 1 in our open handler and erset it
       back to zero in release handler*/
   int in_use = 0;

   /* This function will be invoked each time a user process attempts
       to open our device. You should keep in mind that the prototype
      of this function may change along different kernel versions. */
   static int our_open(struct inode *inode, struct file *file)
   {
      /* We would not like to allow multiple processes to open this device */
      if(in_use)
         return -EBUSY;
      in_use++;
      printk("device has been opened\n");
      return 0;
   }

   /* This function, in turn, will be called when a process closes our device */
   static int our_release(struct inode *inode, struct file *file)
   {
      in_use--;
      printk("device has been closed\n");
      return 0;
   }

   /* This function will handle ioctl calls performed on our device */
   static int our_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
   {
      int retval = 0;
      
      /* We will fill this function in the Part III of this series */

      return retval;
   }

Agora é hora de criar struct file_operations e struct miscdevice e preencher os campos relevantes:

   static const struct file_operations our_fops =\
   {
      .owner = THIS_MODULE,
      .open = &our_open,
      .release = &our_release,
      .unlocked_ioctl = (void*)&our_ioctl,
      .compat_ioctl = (void*)&our_ioctl
   }

Uma pergunta razoável seria: "Por que vamos definir unlocked_ioctl e compat_ioctl com o mesmo valor e onde diabos é o ioctl regular?". Não há nada especial sobre isso. unlocked_ioctl é usado em plataformas de 64 bits e compat_ioctl em 32 bits ou no modo de compatibilidade, e é totalmente normal apontá-las para o mesmo local, desde que a função handler não atrapalhe os tipos acima. Quanto ao ioctl, ele simplesmente não está lá mais...

   static struct miscdevice our_device = \
   {
      MISC_DYNAMIC_MINOR,
      "interceptor",
      &our_fops
   };

Depois de tudo isso, devemos fazer um pequeno ajuste para a nossa função init_module, inserindo o seguinte código:

int retval = misc_register(&our_device);

Você também deve mudar "return 0;" para "return retval;". O código acima diz ao sistema para registrar um dispositivo miscellaneous descrito pela estrutura miscdevice com o kernel. No caso, ao campo menor é atribuído MISC_DYNAMIC_MINOR (nosso caso exatamente), e o kernel preenche com números aleatórios (do nosso ponto de vista), caso contrário, o menor número solicitado é usado.

Nossa função cleanup_module deveria ter esta linha adicionada:

misc_deregister(&our_device);

a fim de cancelar o nosso dispositivo e removê-lo a partir do sistema.

Nota importante: funções do kernel retornam 0 no caso de sucesso, ou um código de erro no caso de falha.

Por agora, temos um modulo de trabalho do kernel que registra um dispositivo miscellaneous quando carregado e o cancela quando descarregado. Construa-o agora com o comando make. Carregue-o com insmod e verifique o conteúdo do sistema de arquivo /dev. Você verá que há um novo dispositivo chamado "interceptor" com o número 10 como número principal e que sempre tem sido atribuído como menor número. Você pode descarregá-lo agora.

Se desejar, você pode tentar abrir e fechar o dispositivo /dev/interceptor de um processo do usuário e verificar o log com dmesg | tail. Você irá visualizar as linhas "device has been opened" e "device has been closed", respectivamente. Você também pode tentar abrir o dispositivo a partir de dois processos de usuário ao mesmo tempo, então você vai ver que apenas um processo pode abri-lo com sucesso.

No próximo artigo, vamos adicionar algum código ao nosso módulo, o que tornaria possível para ele realmente corrigir o sys_call_table e substituir as chamadas originais com wrappers personalizados.

Espero que este artigo tenha sido útil. Vejo vocês na próxima!

⁂

Texto original de Alexey Lyashko, disponível em http://syprog.blogspot.com.br/2011/10/hijack-linux-system-calls-part-ii.html

Alguma vez você já tentou pesquisar no Google por "fragmentando tabela da chamada de sistema Linux"? Existem centenas, senão milhares, de mensagens em relação a esse problema. A maioria delas está desatualizada, pois se refere a kernels mais antigos (aqueles que ainda exportam sys_call_table), outras são sobre a adição de chamada de sistema personalizado e recompilar o kernel. Há algumas que abrangem kernels modernos, mas são sucintas e, principalmente, te dão apenas uma ideia geral de como ele funciona. Decidi fazer uma descrição profunda do processo e fornecer um exemplo que funciona.

Essa descrição consiste em três partes: Módulos, Miscellaneous Character Drivers e System Call Table. Apesar de a segunda parte ser opcional, ela tornaria o seu espaço de código do kernel mais flexível e utilizável a partir da perspectiva do espaço do usuário.

• Módulos - essa parte segue imediatamente este preâmbulo e aborda os conceitos básicos dos módulos do kernel carregáveis.
• Miscellaneous Character Drivers - aqui procuro fornecer explicação aprofundada sobre o que é, como funciona e, o mais importante, como ele pode ser usado.
• System Call Table - essa vai ser a parte mais curta, uma vez que só inclui a estrutura da tabela de chamadas do sistema.
  

Então, vamos mergulhar no negócio.

Módulos do kernel carregáveis

Módulos de kernel carregáveis (LKMs, abreviação do inglês) são simplesmente extensões para o kernel básico em seu sistema operacional que pode ser carregado/descarregado em tempo real, sem a necessidade de recompilar o kernel ou de reiniciar o sistema. Esse recurso existe em todos os principais sistemas operacionais (Windows, Linux, MacOS), mas vamos nos concentrar apenas no Linux, de preferência com o kernel 2.6.38 (já que este é o único que eu testei em exemplos) e superior.

Vá em frente, abra seu editor de código preferido e comece adicionando os arquivos de include necessários:

#include <linux/version.h>
#include <linux/module.h>

Basicamente, isso é tudo que você precisa para construir um módulo simples do kernel que pode ser carregado e descarregado. Iremos, no entanto, adicionar alguns inclusões de módulos mais tarde.

Há mais duas coisas que nós, incondicionalmente, precisamos implementar - Inicialização e rotinas de limpeza. Aqui vamos nós:

static int __init init_module(void) /* You may use any name other than
                                          init_module */
   {
      /* your initialization code goes here */
      /* Once you are done, return 0 to tell the OS that your module
         has been loaded successfully or return relevant error code
         (which must be a negative integer) */
      printk(KERN_INFO "We are in kernel space\n");
      return 0;
   }

Essa é a nossa rotina de inicialização. Se você precisa configurar quaisquer variáveis ou fazer outros arranjos que são cruciais para o módulo, você deve fazer isso aqui.

static void __exit cleanup_module(void) /* Same here - you may use
                                              any name instead of
                                              cleanup_module */
   {
      printk(KERN_INFO "Elvis has left the building\n");
      return;
   }

Por outro lado, a rotina acima é usada para limpar a bagunça que nós produzimos com o nosso módulo. Ela é chamada antes de o módulo ser descarregado.

Como você observou, usamos a função printk aqui - uma das funções mais robustas exportadas pelo kernel do Linux, geralmente usada para mensagens de saída de log/diagnóstico. Você pode obter a sua saída com o comando dmesg.

Use macros module_init e module_exit para traçar essas rotinas:

module_init(init_module);
module_exit(cleanup_module);

E a última coisa - adicionar mais algumas informações ao módulo usando os seguintes macros:

   /* Beware, that some of  kernel functions may not be available 
      to your code if you use license other then GPL */
   MODULE_LICENSE("GPL");
   /* Your name and email goes here */
   MODULE_AUTHOR("your name goes here");
   /* Version of your module */
   MODULE_VERSION("this string is up to you");
   /* Write a line about what this module is */
   MODULE_DESCRIPTION("describe this module here");

É isso aí. Acabamos de construir um skeleton kernel module. Agora temos que compilá-lo. Mas o problema é que você não pode compilar os módulos do kernel da forma que faria com seus aplicativos. Simplesmente porque eles não são aplicativos simples. Você tem que criar um arquivo makefile especial, destacando que é um makefile para um módulo do kernel:

#obj stands for object
#m stands for module/driver
#this is the list of modules that the kernel building system
#needs to build
   obj-m := name_of_the_module.o
#Kernel building system (include files mostly)
#uname -r gives the version of the running kernel
   KDIR := /lib/modules/`uname -r`/build
#current working directory - where to store the output
   PWD := `pwd`
#default build rule
default:
   make -C $(KDIR) M=$(PWD) modules

Execute o comando make e você terá o módulo compilado pronto para ser conectado. Tudo que você precisa fazer agora é tentar carregar o módulo no kernel, e nós temos o comando insmod para esse fim. Use um dos seguintes, dependendo se sua distro é baseada em debian ou em Red Hat, respectivamente:

sudo insmod ./your_module_name.ko

or

su -c "insmod ./your_module_name.ko"

Será solicitada a sua senha ou a senha do root (depende do comando emitido); depois disso, você deve obter a janela de comandos. Se você não receber nenhuma notificação de erro, significa que o módulo foi carregado com êxito, caso contrário, como de costume, verifique o seu código e verifique-o contra suas fontes de kernel. Use o seguinte código para descarregar o módulo:

sudo rmmod your_module_name

or

su -c "rmmod your_module_name"

Você não precisa da extensão ". ko" aqui. Se não receber qualquer notificação de erro, está tudo bem. Mas se receber, isso significaria que, por algumas razões, o sistema é incapaz de descarregar o módulo. A mensagem mais frequente que eu costumava obter era sobre o meu módulo estando ocupado. Às vezes, mesmo rmmod -f não pode resolver esse problema, e você tem que reiniciar a máquina a fim de tirar o seu módulo das mãos de kernel. Claro, você tem que verificar o seu código depois disso, por razões possíveis.

Agora digite "dmesg | tail" para obter o final do log do kernel. As últimas duas linhas devem conter as strings que passamos para função printk ou a razão de não ser capaz de descarregar o módulo. É importante executar esse comando antes de reiniciar em caso de erro a fim de ver a razão, caso contrário, você não encontrará essa entrada.

Conclusão

Então acabamos de construir nosso módulo mais simples. Na prática, isso não é verdade, já que o módulo mais simples não deve conter printk :). Somos (espero) capazes de carregar e descarregá-lo.

No próximo artigo, vamos adicionar um dispositivo virtual, que seria responsável pela interação com um processo de usuário e executaria todas as operações de aplicação de patches/correção.

Espero que este artigo tenha sido útil. Vejo vocês na próxima!

⁂

Texto original de Alexey Lyashko, disponível em http://syprog.blogspot.com.br/2011/10/hijack-linux-system-calls-part-i.html

Alguma vez você já tentou pesquisar no Google por "fragmentando tabela da chamada de sistema Linux"? Existem centenas, senão milhares, de mensagens em relação a esse problema. A maioria delas está desatualizada, pois se refere a kernels mais antigos (aqueles que ainda exportam sys_call_table), outras são sobre a adição de chamada de sistema personalizado e recompilar o kernel. Há algumas que abrangem kernels modernos, mas são sucintas e, principalmente, te dão apenas uma ideia geral de como ele funciona. Decidi fazer uma descrição profunda do processo e fornecer um exemplo que funciona.

Essa descrição consiste em três partes: Módulos, Miscellaneous Character Drivers e System Call Table. Apesar de a segunda parte ser opcional, ela tornaria o seu espaço de código do kernel mais flexível e utilizável a partir da perspectiva do espaço do usuário.

• Módulos - essa parte segue imediatamente este preâmbulo e aborda os conceitos básicos dos módulos do kernel carregáveis.
• Miscellaneous Character Drivers - aqui procuro fornecer explicação aprofundada sobre o que é, como funciona e, o mais importante, como ele pode ser usado.
• System Call Table - essa vai ser a parte mais curta, uma vez que só inclui a estrutura da tabela de chamadas do sistema.
  

Então, vamos mergulhar no negócio.

Módulos do kernel carregáveis

Módulos de kernel carregáveis (LKMs, abreviação do inglês) são simplesmente extensões para o kernel básico em seu sistema operacional que pode ser carregado/descarregado em tempo real, sem a necessidade de recompilar o kernel ou de reiniciar o sistema. Esse recurso existe em todos os principais sistemas operacionais (Windows, Linux, MacOS), mas vamos nos concentrar apenas no Linux, de preferência com o kernel 2.6.38 (já que este é o único que eu testei em exemplos) e superior.

Vá em frente, abra seu editor de código preferido e comece adicionando os arquivos de include necessários:

#include <linux/version.h>
#include <linux/module.h>

Basicamente, isso é tudo que você precisa para construir um módulo simples do kernel que pode ser carregado e descarregado. Iremos, no entanto, adicionar alguns inclusões de módulos mais tarde.

Há mais duas coisas que nós, incondicionalmente, precisamos implementar - Inicialização e rotinas de limpeza. Aqui vamos nós:

static int __init init_module(void) /* You may use any name other than
                                          init_module */
   {
      /* your initialization code goes here */
      /* Once you are done, return 0 to tell the OS that your module
         has been loaded successfully or return relevant error code
         (which must be a negative integer) */
      printk(KERN_INFO "We are in kernel space\n");
      return 0;
   }

Essa é a nossa rotina de inicialização. Se você precisa configurar quaisquer variáveis ou fazer outros arranjos que são cruciais para o módulo, você deve fazer isso aqui.

static void __exit cleanup_module(void) /* Same here - you may use
                                              any name instead of
                                              cleanup_module */
   {
      printk(KERN_INFO "Elvis has left the building\n");
      return;
   }

Por outro lado, a rotina acima é usada para limpar a bagunça que nós produzimos com o nosso módulo. Ela é chamada antes de o módulo ser descarregado.

Como você observou, usamos a função printk aqui - uma das funções mais robustas exportadas pelo kernel do Linux, geralmente usada para mensagens de saída de log/diagnóstico. Você pode obter a sua saída com o comando dmesg.

Use macros module_init e module_exit para traçar essas rotinas:

module_init(init_module);
module_exit(cleanup_module);

E a última coisa - adicionar mais algumas informações ao módulo usando os seguintes macros:

   /* Beware, that some of  kernel functions may not be available 
      to your code if you use license other then GPL */
   MODULE_LICENSE("GPL");
   /* Your name and email goes here */
   MODULE_AUTHOR("your name goes here");
   /* Version of your module */
   MODULE_VERSION("this string is up to you");
   /* Write a line about what this module is */
   MODULE_DESCRIPTION("describe this module here");

É isso aí. Acabamos de construir um skeleton kernel module. Agora temos que compilá-lo. Mas o problema é que você não pode compilar os módulos do kernel da forma que faria com seus aplicativos. Simplesmente porque eles não são aplicativos simples. Você tem que criar um arquivo makefile especial, destacando que é um makefile para um módulo do kernel:

#obj stands for object
#m stands for module/driver
#this is the list of modules that the kernel building system
#needs to build
   obj-m := name_of_the_module.o
#Kernel building system (include files mostly)
#uname -r gives the version of the running kernel
   KDIR := /lib/modules/`uname -r`/build
#current working directory - where to store the output
   PWD := `pwd`
#default build rule
default:
   make -C $(KDIR) M=$(PWD) modules

Execute o comando make e você terá o módulo compilado pronto para ser conectado. Tudo que você precisa fazer agora é tentar carregar o módulo no kernel, e nós temos o comando insmod para esse fim. Use um dos seguintes, dependendo se sua distro é baseada em debian ou em Red Hat, respectivamente:

sudo insmod ./your_module_name.ko

or

su -c "insmod ./your_module_name.ko"

Será solicitada a sua senha ou a senha do root (depende do comando emitido); depois disso, você deve obter a janela de comandos. Se você não receber nenhuma notificação de erro, significa que o módulo foi carregado com êxito, caso contrário, como de costume, verifique o seu código e verifique-o contra suas fontes de kernel. Use o seguinte código para descarregar o módulo:

sudo rmmod your_module_name

or

su -c "rmmod your_module_name"

Você não precisa da extensão ". ko" aqui. Se não receber qualquer notificação de erro, está tudo bem. Mas se receber, isso significaria que, por algumas razões, o sistema é incapaz de descarregar o módulo. A mensagem mais frequente que eu costumava obter era sobre o meu módulo estando ocupado. Às vezes, mesmo rmmod -f não pode resolver esse problema, e você tem que reiniciar a máquina a fim de tirar o seu módulo das mãos de kernel. Claro, você tem que verificar o seu código depois disso, por razões possíveis.

Agora digite "dmesg | tail" para obter o final do log do kernel. As últimas duas linhas devem conter as strings que passamos para função printk ou a razão de não ser capaz de descarregar o módulo. É importante executar esse comando antes de reiniciar em caso de erro a fim de ver a razão, caso contrário, você não encontrará essa entrada.

Conclusão

Então acabamos de construir nosso módulo mais simples. Na prática, isso não é verdade, já que o módulo mais simples não deve conter printk :). Somos (espero) capazes de carregar e descarregá-lo.

No próximo artigo, vamos adicionar um dispositivo virtual, que seria responsável pela interação com um processo de usuário e executaria todas as operações de aplicação de patches/correção.

Espero que este artigo tenha sido útil. Vejo vocês na próxima!

⁂

Texto original de Alexey Lyashko, disponível em http://syprog.blogspot.com.br/2011/10/hijack-linux-system-calls-part-i.html

Veja neste artigo a instalação do sistema de detecção de intrusão na rede Snort, logando no banco de dados MySQL através do BarnYard2 e visualizando os logs e gráficos gerenciais pelo Snorby, rodando no servidor Web Apache2, tudo isso dentro do Debian.

Instalando o MySQL

Instalando o MySQL:

# apt-get install mysql-server-5.1 mysql-client libmysqlclient-dev libpcap-dev

Durante a instalação, será pedida a senha para o usuário root do MySQL, mas, se houver algum problema, configure a senha do root do MySQL com o comando:

# mysqladmin -u root password senharootdomysql

Vamos criar o banco de dados e o usuário para acessá-lo:

# mysql -u root -p

Já no shell do MySQL:

CREATE DATABASE snort;
GRANT all privileges ON snort.* TO snort@localhost IDENTIFIED BY 'senha_snort_mysql';
flush privileges;
QUIT

Instalando o SNORT

Instalando o SNORT:

# apt-get install snort-mysql snort-rules-default

Criando as tabelas para o snort:

# zcat /usr/share/doc/snort-mysql/create_mysql.gz | mysql -u snort -h localhost -p snort

Agora vamos configurar o SNORT editando o arquivo /etc/snort/snort.debian.conf.

Primeiro, configure a rede interna no parâmetro já existente:

DEBIAN_SNORT_HOME_NET=”127.0.0.0/16,192.168.0.0/24”

Interface usada:

DEBIAN_SNORT_INTERFACE=”eth0”

Vamos dizer para o SNORT usar o banco de dados do MySQL, editando o arquivo /etc/snort/database.conf e coloque:

output database: log, mysql, user=snort password=snort_pwd dbname=snort host=localhost

Remova o arquivo de “pendência” do banco de dados para o snort:

# rm -rf /etc/snort/db-pending-config

Reinicie o SNORT e pronto, já está funcionando e registrando no MySQL:

# /etc/init.d/snort restart

Instalando o BarnYard2

Baixe o banryard2 e instale:

# tar xvf barnyard2-1.8.tar.gz
# cd barnyard2-1.8
# ./configure --with-mysql
# make
# make install
# cd etc
# cp barnyard2.conf /etc/snort

Vamos configurar o arquivo /etc/snort/database.conf. Comente com “#” a linha que diz respeito ao MySQL:

#output database: log, mysql, user=snort password=senha_snort_mysql dbname=snort host=localhost

Adicione a linha:

output unified2: filename snort.out, limit 128

Agora vamos editar o arquivo /etc/snort/barnyard2.conf:

config daemon
config hostname: localhost
config interface: eth0
config logdir: /var/log/barnyard2/
config waldo_file: /var/barnyard2/waldo

Acrescente no final a linha:

output database: log, mysql, user=snort password=senha_snort_mysql dbname=snort host=localhost

Vamos criar as pastas para o uso do barnyard2:

# mkdir /var/log/barnyard2
# mkdir /var/barnyard2

Vamos reiniciar o SNORT:

# /etc/init.d/snort restart

Iniciando o BarnYard2:

# cd /etc/snort
# barnyard2 -d /var/log/snort -f snort.out
*** Os 
comandos acima para inicialização do BarnYard2 deverão ser executados 
sempre na inicialização do sistema, sugiro colocá-los no /etc/rc.local 
***

Instalando o Apache2

Instale o apache e alguns requisitos:

# aptitude install apache2 apache2-prefork-dev libapr1-dev libaprutil1-dev libopenssl-ruby libcurl4-openssl-dev gem

Instalando o SNORBY

Vamos instalar os requisitos para o Snorby:

# aptitude install gcc g++ build-essential libssl-dev libreadline5-dev zlib1g-dev linux-headers-generic libsqlite3-dev libxslt-dev libxml2-dev imagemagick git-core libmagickwand-dev default-jre

Instale o wkhtmltopdf:

# wget http://wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.10.0_rc2-static-i386.tar.bz2
# tar xvjf wkhtmltopdf-0.10.0_rc2-static-i386.tar.bz2
# cp wkhtmltopdf-i386 /usr/sbin/wkhtmltopdf

Instalando o ruby:

# wget http://ftp.ruby-lang.org//pub/ruby/1.9/ruby-1.9.2-p290.tar.gz
# tar -xvzf ruby-1.9.2-p290.tar.gz
# cd ruby-1.9.2-p290
# ./configure
# make && make install

Vemos a versão instalada:

# ruby -v
ruby 1.9.2p290 (2010-08-18 revision 29036) [i686-linux]

Instalamos os gems:

# gem install thor i18n bundler
# gem install tzinfo builder memcache-client rack rack-test erubis mail text-format sqlite3-ruby
# gem install rack-mount --version=0.4.0
# gem install rails --version=3.0.0

Instalando Snorby:

# git clone http://github.com/Snorby/snorby.git /var/www/snorby

Editamos o arquivo de configuração do banco de dados:
# vi /var/www/snorby/config/database.yml
snorby: &snorby
adapter: mysql
username: snort
password: senha_snort_mysql
host: localhost

Editamos o arquivo de configuração do Snorby:
# vi /var/www/snorby/config/snorby_config.yml

development:
domain: localhost:3000
wkhtmltopdf: /usr/sbin/wkhtmltopdf

test:
domain: localhost:3000
wkhtmltopdf: /usr/sbin/wkhtmltopdf

production:
domain: localhost:3000
wkhtmltopdf: /usr/sbin/wkhtmltopdf

Já no shell do MySQL:

GRANT all privileges ON snorby.* TO snort@localhost;
flush privileges;
QUIT

Instalando o Snorby:

# cd /var/www/snorby
# bundle install
# rake snorby:setup RAILS_ENV=production

Vamos criar o acesso do usuário snort no banco de dados do Snorby:

# mysql -u root -p

Edite o arquivo /etc/snort/barnyard2.conf e acrescente a linha:

output database: log, mysql, user=snort password=senha_snort_mysql dbname=snorby host=localhost

Editando o Apache2

Instalando o módulo passenger:

# gem install --no-ri --no-rdoc --version 3.0.3 passenger
# cd /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.3/bin
# ./passenger-install-apache2-module -a

Vamos criar o arquivo do módulo para o Apache2:

# vi /etc/apache2/mods-available/passenger.load

Adicione no arquivo:

LoadModule passenger_module /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.3/ext/apache2/mod_passenger.so

Vamos habilitar o módulo:

# vi /etc/apache2/mods-available/passenger.conf

Adicione no arquivo:

<IfModule mod_passenger.c>
    PassengerRoot /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.3
    PassengerRuby /usr/local/bin/ruby
</IfModule>

Instalando o módulo:

# a2enmod passenger
# a2enmod rewrite
# a2enmod ssl

Reinicie o apache2:

# /etc/init.d/apache2 restart

Edite o arquivo /etc/apache2/sites-available/default:

<Virtualhost *:80>
#   ServerName infosegura
   DocumentRoot /var/www/snorby/public/

   <Directory /var/www/snorby/public>
    RailsBaseURI /
          Options +ExecCGI FollowSymLinks -MultiViews
          AllowOverride all
          Order allow,deny
          Allow from all
   </Directory>

Reinicie o apache2:

# /etc/init.d/apache2 restart

Vamos reiniciar o SNORT:

# /etc/init.d/snort restart

Iniciando o Snorby:

# cd /var/www/snorby
# ruby script/delayed_job start -e production
*** Os comandos acima para inicialização do Snorby deverão ser executados sempre na inicialização do sistema, sugiro colocá-los no /etc/rc.local ***

Acesse pelo navegador o Snorby: http://<ip_snorby>

Coloque o usuário e senha:

• Usuário: snorby@snorby.org
• Senha: snorby

Tela principal, na qual o “Dashboard” é atualizado a cada 30 min e os eventos são atualizados imediatamente:

Verifique se o Snorby Worker está funcionando clicando em “Administration > Administrator Menu > Worker & Job Queue".

Dica

Crie o script abaixo para executar o Barnyard2 na inicialização do sistema:

#!/bin/sh

case $1 in
        start)
                printf "starting $0..."
       cd /etc/snort
                barnyard2 -d /var/log/snort -f snort.out
                echo -e 'OK'
        ;;
        stop)
                printf "stopping $0..."
                killall barnyard2
                echo -e 'OK'
        ;;
        restart)
                $0 stop
                $0 start
        ;;
        *)
                echo "usage: $0 (start|stop|restart)"
        ;;
esac
Para executar acrescente no /etc/rc.local:
/caminho/nome_script_barnyard2 start

Para executar o Snorby na inicialização do sistema, crie o script:

#!/bin/bash

cd /var/www/snorby
/usr/local/bin/ruby script/delayed_job start -e production

Para executar acrescente no /etc/rc.local:

/caminho/nome_script_snorby

Atualizar o Snorby

O projeto Snorby está em constante desenvolvimento, por isso, se quiser atualizar o seu, é necessário o RAKE:

# gem install rake

Entre no diretório de instalação do Snorby:

# cd /var/www/snorby 

Vamos utilizar o GIT para a atualização. Diga a ele que seus arquivos estão nesse diretório...

# git add .
# git commit -m 'Coloque seu comentário aqui' 

Verifica as atualizações disponíveis:

# git rm Gemfile.lock && git pull origin master 

Atualize as dependências:

# gem update --system
# bundle install --path vendor/cache 

Edite o arquivo com as credenciais de acesso ao banco de dados MySQL e coloque o usuário e senha de acesso ao banco do Snorby:

# vi config/database.yml

Atualize o Snorby:

# rake snorby:update

Acesse pelo navegador o Snorby: http://<ip_snorby>

Referências:

• http://muchikon.blogspot.com/2011/03/snorby-225-en-debian-wheezy.html
• https://lswiki.byu.edu/index.php/Snort,_Barnyard2,_and_Snorby
• http://www.vivaolinux.com.br/artigo/Debian-Sarge-+-Snort-+-MySQL-+-Acidlab-+-Ap

Neste artigo abordaremos um tema fundamental para administradores de sistemas GNU/Linux e também para usuários avançados deste sistema: o gerenciamento de pontos de montagem em modo Shell. Todas as técnicas explanadas neste artigo são aplicáveis a qualquer distro GNU/Linux.

Fonte: Tecnoblog

Mark Shuttleworth, fundador da Canonical, afirmou ao The Register que a proposta do software é abandonar o ciclo de novas versões a cada seis meses e passar para um modelo de atualizações diárias, no estilo rolling release - uma modalidade em que as atualizações ocorrem de forma continuada, sem que seja necessário reinstalar parte do sistema a cada atualização maior.

Outras distribuições Linux já utilizam esse modelo, como o Gentoo, o Arch e o PCLinuxOS.

Mark também comentou que o interesse da Canonical é fazer o Ubuntu acompanhar a velocidade de desenvolvimento de novos softwares e serviços. "Em um mundo orientado para a internet, precisamos estar preparados para lançar uma novidade por dia", afirmou Mark.

Agora é aguardar e ver como esse modelo será implementado.

Por Paulo Graveheart

---

notícia publicada originalmente no iMasters, em 25 de novembro de 2010.

A Fundação Linux agora possui seu próprio cartão de crédito, que já está disponível para consumidores americanos que quiserem apoiar a iniciativa e os produtos da organização.

O cartão funciona sob a bandeira Visa e surgiu da parceria entre o banco UMB e a CardPartner, uma empresa que permite que ONGs criem seus cartões de cédito para arrecadar fundos.

De acordo com a Fundação, o cartão não possui taxa anual, e o usuário ganha pontos é medida que o utiliza. Cada ativação do cartão dará US$ 50 para a Fundação Linux, que também receberá uma pequena porcentagem das transações feitas com ele.

A receita será utilizada em "eventos técnicos da entidade e no financiamento das viagens dos membros da comunidade open-sorce, de modo a acelerar a inovação do Linux".

O cartão provavelmente não estará disponível fora dos Estados Unidos por causa da dificuldade de encontrar parceiros em outros países, afirmou a Fundação Linux.

Com informações de Geek

---

notícia publicada originalmente no iMasters, em 03 de novembro de 2010.