Petryx Divulgando Conhecimento.

Posix capabilities permite que as capacidades do super usuário root sejam delegadas a binários, possibilitando que usuários comuns possam executar um serviço. Usando esse recurso de forma correta pode-se executar serviços utilizando somente as capacidades mínimas, ao contrário de executar com todos os privilégios do root.

Publiquei um artigo na revista Linux Magazine Ed. 48 mostrando como usar Posix Capabilities para rodar serviços como: Samba, Dns e apache. Reduzindo os chances de acontecer um ataque de buffer overflow, onde se consiga abrir um terminal de super usuário.

Para descobrir as capacidades exigidas pelos serviços reescrevi o módulo de kernel capable_probe desenvolvido originalmente por Serge E. Hallyn. Na primeira versão usei jprobe ao invés de kprobe, fiz uma associação entre o valor numérico e a string. Ex. 21:CAP_SYS_ADMIN. Porém, esse código pode encher os logs do sistema, pois captura todos os processos que estão rodando. Para sanar o problema, reescrevi o módulo para que aceite como parâmetro o processo que se deseja monitorar, reduzindo dessa forma as mensagens duplicadas no log.

Download do módulo

wget http://petryx.blogrs.com.br/capable_discovery-0.1.0.tar.bz2

Instalação

tar -xjvf capable_discovery-0.1.0.tar.bz2
cd capable_discovery-0.1.0
make
make install

Utilização

Por exemplo, queremos descobrir qual as capacidades exigidas para rodar o comando ping.

modprobe capable_discovery catch=ping
ping 127.0.0.1

Em outro terminal

tail -f /var/log/messages
localhost Module capable_discovery inserted for discover the capabilities of "ping" process
localhost capability 21=CAP_SYS_ADMIN for ping
localhost capability 13=CAP_NET_RAW for ping
localhost capability 7=CAP_SETUID for ping
localhost capability 21=CAP_SYS_ADMIN for ping
localhost capability 21=CAP_SYS_ADMIN for ping

Como podemos ver o ping precisa das capacidades 7,13,21

Após usar o módulo devemos removê-lo com o seguinte comando:

rmmod  capable_discovery

Confirmando a remoção do módulo irá aparecer nos logs a seguinte mensagem:

Nov 16 11:57:06 localhost Module capable_discovery unregistered

Para monitar outro processo o módulo deve ser recarregado passando como parâmetro o nome do processo.

Qualquer dúvida,sugestão, crítica ou elogio, deixe um comentário.

Quem já passou por isso ?
A uns dias atrás fui ligar meu notebook e recebi a seguinte mensagem: Operation System not found. Corri na prateleira para pegar o cd de boot do Kurumin, inicializou sem problemas, o hd foi encontrado na inicialização. Mas, sem nenhuma partição. Depois de alguns minutos tentando contabilizar tudo que tinha perdido, algo em torno de 90GB de informação, como por exemplo, códigos fontes, livros, trabalhos da faculdade, artigos, monografia. Claro que tudo tinha backup, mas desatualizado no mínimo 3 meses.
Então começou a saga para tentar resolver o problema. Encontrei dois utilitários gpart e testdisk, estes programas escaneiam o HD em busca do início e do final das partições, a diferença entre eles é o algoritmo de busca.
Comecei utilizando o gpart conforme o comando abaixo. O qual escaneou o HD e não encontrou nenhuma partição, sendo que para escanear o HD levou umas boas horas.
./gpart.linux /dev/hda

Dando seguimento a saga para recuperar algo, tentei o testdisk. Já esse encontrou algumas partições primárias e outras estendidas. Fiquei loco de faceiro, pensei! solucionei o problema. Reiniciei a máquina quando fui montar as partições, somente obtive erros.

Ainda não desiste estou tentando novamente o gpart com alguns parâmetros diferentes. Para encontrar a tabela certinha é necessário que a geometria do disco esteja correta, ou seja, os parâmetros: número de cilindros(cylinders), cabeças(heads) e setores (sectors) estejam corretos. Esse valores podem ser descobertos com o seguinte comando:

#/dmesg | grep CHS

Ajustei os parâmetros no gpart.

gpart -C C,H,S /dev/hda

Onde C é número de cilindros, H heads ,….

Neste momento estou executando novamente o gpart. Desta vez já estou com os dedos cruzados.

Uma dica fácil e muito útil faça um backup da sua tabela de partição com o comando abaixo, será muito útil.

Backup da tabela de partições

dd if=/dev/hda of=hda.mbr bs=512 count=1

Fomato legível

fdisk -l > partitions.txt

Restaurar

dd if=hda.mbr of=/dev/hda bs=512 count=1

Ahh!!!. Se eu tivesse feito isso antes.

Grande abraço a todos.

Cscope é uma ferramenta que auxilia a analisar o código fonte de um projeto. Com ele podemos entender a estrutura do projeto ou o significado de uma função específica, estruturas e variáveis. Descobrir aonde funções específicas são utilizadas, determinar qual função chama uma função específica. Sendo estes alguns recursos do cscope.

A ferramenta foi desenvolvida para a linguagem C, utilizando-a podemos economizar um bom tempo na analise de um projeto.

Utilizando o cscope

Cscope analisa os fontes encontrados no diretório atual, mas podemos usar a opção -r para varrer recursivamente os diretórios do projeto.

Na página do projeto tem um excelente tutorial. O tutorial tem como objetivo utilizar o cscope para analisar o código fonte do kernel.

Segui o tutorial, é muito legal facilita bastante o entendimento do código fonte.

TCPDUMP é um sniffer de rede por linha de comando, sendo uma alternativa ao wireshark ou quando é necessário fazer um script para capturar algum tráfego de rede. Enfim uma ferramenta muito útil para administrar uma rede sendo possível descobrir erros de configuração através da analise do tráfego, conhecer o tráfego existente e tomar medidas administrativas para melhorar a performance da rede.
Executando o tcpdump sem nenhuma opção, será capturado todo o tráfego de rede, dificultando a analise do conteúdo, por isso é interessante o uso de expressões.
Com Tcpdump podemos usar expressões para filtrar o tráfego que desejamos capturar, os filtros podem ser aplicados por tipo, direção, protocolo, usando operadores, …

Alguns exemplos:

Mostra somente o tráfego da rede 192.168 que estiver passando na interface eth0

localhost ~/# tcpdump -i eth0 -p net 192.168

Mostra todo o tráfego da rede 192.168 com destino a porta 80

localhost ~/# tcpdump -i eth0 -p net 192.168 and dst port 80

Mostra somente os pacotes icmp na rede

localhost ~/# tcpdump -i eth0 -p icmp

Mostra o tráfego na rede 192.168 com exceção da porta 80

localhost ~/# tcpdump -i eth0 -p net 192.168 and not port 80

Os exemplos acima demonstram algumas combinações, sendo possível fazer muito mais. Para obter mais informações veja o documento TCPDUMP filters.

Se o artigo foi útil para você, deixe um comentário. Será de grande estimulo para manter o blog.

Traceroute é um algoritmo definido pela rfc1393. Contudo antes de sabermos como funciona o traceroute é necessário entendermos o que é TTL (Time To Live). TTL significa o tempo de vida de um pacote na rede, cada vez que um pacote passa por um roteador o TTL é decrementado em uma unidade. Pode ocorrer de uma rede entrar em loop por erro de configuração no roteador ou defeito, então esse pacote fica eternamente circulando na rede. Para que isso não ocorra o TTL é fundamental pois quando chegar a zero o roteador descarta o pacote. Outro uso do TTL é descobrir quantos roteadores têm até um determinado host, sendo essa a função do traceroute.

Como funciona o traceroute

O traceroute envia 3 pacotes com o TTL igual a 1. O primeiro hop responde que o pacote não pode ser transmitido porque TTL expirou com a mensagem ICMP Time-to-Live Exceeded (Type 11). Então o pacote é reenviado com TTL igual a 2 e o segundo roteador responde que o TTL expirou. Este processo continua até o destino ser encontrado.
Com o traceroute conseguimos somente o caminho de ida até o destino, não sendo possível obter o caminho de retorno que pode ser diferente.

Testando o traceroute

% traceroute www.terra.com.br
traceroute to www.terra.com.br (200.176.3.142), 30 hops max, 40 byte packets
 1   (192.168.254.254)  5.108 ms  6.458 ms  7.921 ms
 2  BrT-L10-smace701.dsl.brasiltelecom.net.br (201.14.223.254)  54.958 ms  56.458 ms  57.833 ms
 3  BrT-G5-0-0-710-smace300.brasiltelecom.net.br (201.10.227.133)  67.548 ms  73.977 ms  76.842 ms
 4  * * *
 5  BrT-G6-0-0-paebvcore01.brasiltelecom.net.br (201.10.255.162)  95.781 ms  102.036 ms  100.632 ms
 6  * * *
 7   (200.176.0.250)  55.624 ms  57.064 ms  59.931 ms
 8  bsw5-poa-vlan201.tc.terra.com.br (200.176.2.28)  61.487 ms  79.703 ms  81.222 ms

A resposta do traceroute mostra três tempos, isso é porque quando um roteador é encontrado o mesmo é testado três vezes. Já quando aparece como resposta * * * significa que esse roteador não respondeu que o TTL expirou.
Existem muitas opções que podem ser usadas com o traceroute, como por exemplo, usar o protocolo tcp em vez de icmp. Para saber mais sobre as opções consulte man traceroute.

Se você é programador C e quiser ver como o traceroute é implementado, vale a pena baixar os fontes e analisar o código. É uma experiência e tanto!

Existe um programa chamado VisualRoute. Esse programa traça a rota sobre o mapa mundi informando o país onde está cada roteador até o destino.

Por hoje era isso. Ah, pessoal estamos com uma super promoção essa semana, assinem os feeds gratuitamente. Mas somente essa semana!

Eu sempre quis saber como era a implementação da rede no linux depois de pesquisar um pouco no pai dos curiosos (google), encontrei um excelente documento que explica como é implementada a pilha de protocolos de rede no Linux.

Vale a pena ler.

Linux IP Networking

Se você quer saber quais tipos de partição (ext3,nfs,jfs,…), seu kernel suporte execute o comando:

% cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   cgroup
nodev   securityfs
nodev   sockfs
nodev   usbfs
nodev   pipefs
nodev   anon_inodefs
nodev   tmpfs
nodev   inotifyfs
nodev   devpts
           reiserfs
           ext3
           ext4dev
           ext2
nodev   ramfs
nodev   hugetlbfs
           msdos
           vfat
           iso9660
.
.
.

Se necessitar de algum tipo em especial de partição recompile o kernel.

Se quiser saber o que mais tem de interessante dentro do /proc leia o que tem dentro /proc.

Com o comando net no linux é possível realizar muitas tarefas de administração de servidores samba e windows irei colocar neste artigo alguns exemplos.

Os comando abaixo se aplicam a um servidor linux rodando o samba, máquina com windows xp, servidor windows NT4.

Desligar remotamente

# net rpc shutdown -S maquina10 -U administrador

Reiniciar a máquina com mensagem personalizada

# net rpc shutdown -r -S maquina10 -C ‘atualizando a maquina’ -U administrador

Abortar o comando de desligamento remoto

# net rpc abortshutdown -S maquina10 -Uadministrador

Listar os grupos de usuários

# net rpc group list -S maquina10 -Uadministrador
onde “maquina10″ é o nome do computador na rede.

Listar os usuários

#net rpc user -S maquina10 -Uadministrador

Referências

http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetCommand.html

Necessita de consultoria em servidores linux ? Entre em contato

Para corrigir bugs e falhas de segurança recorremos as atualizações fornecidas pelos gerenciador de pacote da distribuição que utilizamos.
Mas se o gerenciador de pacotes não é seguro !!

Gerenciadores de pacotes rodam normalmente com acesso irrestrito, ou seja, como root para permitir modificação críticas no sistema. O gerenciador de pacote afeta o sistema inteiro e torna-se vital para a segurança e bom funcionamento do mesmo.

A universidade de Arizona analisou 10 gerenciadores de pacotes (APT, YUM, YaST, etc.).
E descobriu que é possível realizar um ataque conhecido como Replay Attacks.

Com esse ataque um invasor pode reproduzir corretamente as assinaturas dos pacotes ou metadados a partir de uma versão anterior. Fazendo com que os usuários instalem um pacote com BUG para o invasor explorar. Podendo abrir backdoors, ler ou apagar arquivos, sem comprometer senhas ou chaves de segurança.

Como se proteger

• Usar Repositórios Confiáveis:. Use somente mirrors que pertencem a organização de confiança. Não escolha os repositórios randomicamente em uma lista de mirrors.
• Atualiza manualmente seus sistemas (local e mirror caches):. Conheça o pacote e descubra quando as atualizações disponíveis e quais devem ser as versões. Verifique e instale manualmente os pacotes atualizados ao invés de utilizar atualizações automáticas.
• Use repositórios com metadados assinados: Se o gerenciador de pacotes ou a distro ainda não assina os metadados, mas apenas pacotes, pelo menos exiga pacotes assinados até suportar metadados assinados.
• Use HTTPS para comunicar com o mirror:Infelizmente suporte a HTTPS geralmente só está disponível para suporte pago (mas só protege contra um ataque conhecido como man-in-middle, não protege contra mirrors maliciosos).

Segundo a universidade do Arizona o problema pode ocorrer em ferramentas como yum e apt.

Referências:
Attacks On Package Managers
Study: Attacks on package managers

A algum tempo atrás, surgiu a necessidade de saber o tamanho de cada tabela em bytes, numa base de dados (database) Postgresql. Era necessário para estimar o crescimento destas tabelas e saber quanto tempo levaria que esgotar a capacidade do HD.
Nesta pesquisa encontrei muitos dados interessantes que irei compartilhar com vocês. Claro que para alguns não terá novidade nenhuma nesta matéria, mas com certeza será valioso para alguém como foi para mim.

Antes de começar temos que entender como o postgresql gerencia os arquivos da base de dados, então vamos explora-lo.

Como PostgreSQL gerencia os arquivos da base de dados ?

O conceito fundamental do Postgresql e de outros SGBDS é que os dados são armazenados em tabelas e as tabelas agrupadas em base de dados (databases). Em um nível mais alto desta organização as base de dados são agrupadas em clusters – e um cluster de base de dados é gerenciado pelo postmaster.

E como fica essa hierarquia no disco ?

Para descobrir como funciona essa hierarquia na prática vamos fazer umas consultas (queries) , executar um comandos no shell.
Vamos começar conectando a base de dados e descobrindo o OID (Obect ID) através de uma consulta.

~$ psql book -U postgres

book=# SELECT datname, oid from pg_database;

(4 registros)

Na resposta da nossa query podemos ver que temos 4 base de dados (databases) no cluster. Agora podemos encontrar as base de dados no disco dentro do diretório $PG_DATA.

~$ cd $PG_DATA
~$ ls
base pg_clog pg_ident.conf pg_subtrans pg_twophase pg_xlog postmaster.opts
global pg_hba.conf pg_multixact pg_tblspc PG_VERSION postgresql.conf postmaster.pid

Dentro do subdiretório base encontra-se as base de dados no SELECT que executamos antes tem um oid 1 para a base de dados (datname) template1. Vamos entrar dentro do diretório base e ver o que tem por lá.
~$ cd base
~$ ls -la
drwx—— 2 postgres postgres 2648 Jul 11 11:17 1
drwx—— 2 postgres postgres 2648 Jul 11 11:17 10818
drwx—— 2 postgres postgres 2680 Jul 11 11:18 10819
drwx—— 2 postgres postgres 2680 Jul 11 11:39 16384

Neste exemplo temos 4 diretórios o mesmo números de registros quando executamos o SELECT então isso demonstra que o OID(object ID) corresponde ao nome do diretorio dentro da base de dados. Como exemplo o diretórios 1 corresponde a base de dados template1.
Entrando no diretório 1 podemos ver que existem vários arquivos vamos descobrir o que significa cada um deles.

~$ cd 1
~$ ls
10737 10747 10757 10767 1250 2603 2609 2615 2650 2656 2662 2668 2678 2684 690 2700 2831 2837 10739 10749 10759 10769 1255 2604 2610 2616 2651 2657 2663 2669
….
….

Para saber o que significa cada um desses arquivos temos que descobrir os OIDS dentro da base de dados template1. Vamos voltar ao psql

~$ psql -q -d template1
template1=# select oid, relname from pg_class;

Na tabela pg_class existe mais informação que pode nos ajudar a explorar a estrutura de armazenamento do PostgreSQL.

psql book -Upostgres
book=# select relname,oid,relpages, reltuples FROM pg_class ORDER BY OID;

A coluna reltuples informa quantas tuplas tem em cada tabela. Já a coluna relpages mostra quantas páginas (pages) são requiridas para armazenar o conteúdo da tabela.

Qual a correspondência entre relpages e reltuples com o tamanho do arquivo no disco ?

Vamos listar o conteúdo do diretório e pegar dois exemplos

$ ls -l 1247 1249
-rw------- 1 postgres postgres  40960 Jul  11 11:17 1247
-rw------- 1 postgres postgres 229376 Jul 11 11:17 1249

O arquivo chamado 1247 tabela pg_type ocupa um espaço em disco e 40960 bytes. Se dividirmos 40960/5 relpages = 8192 bytes, realizando o mesmo cálculo para a tabela pg_attribute que corresponde ao arquivo 1249 que possui um tamanho em disco de 229376 bytes / 28 relpages = 8192 bytes.
O tamanho 8192 refere-se ao tamanho da página este valor é fixo como podemos verificar.

Com esta matéria acho que consegui mostrar como o PostgreSQL estrutura os dados no disco.
E como descobrir o tamanho da tabela no Hd, com certeza existe outras maneiras mas escolhi está para demonstrar também como o postgresql organiza as tabelas no HD.

Referência:
Livro PostgreSQL - Korry Douglas e Susan Douglas