Faz parte da mitologia grega, cerberus ou kerberos era um cão de três cabeças e cobras ao redor do pescoço que guardava o reino subterrâneo dos mortos, o qual Hades deus da guerra era o “mentor”, hades irmão de Zeus e filho de Cronos . Bom mitologia grega não é o foco, nosso objetivo e falar sobre o software kerberos, assim como o cerberus protege o reino de Hades o nosso kerberos pode proteger nossa infra-estrutura de rede, fazer o controle de acesso.

O kerberos se diferencia dos outros metódos de controle de acesso por autenticar o usuário apenas uma única vez depois disso ele trabalha com o que chamamos de tickets ou “segredos”.
Ele faz a autenticação de usuários, computadores ou hosts e serviços de rede, tais como e-mail, http, ftp esses serviços que suportam kerberos damos o nome de “serviços kerberizados”, cada usuário, host ou serviços na linguagem do kerberos recebe o nome de “principal”. O kerberos utiliza um “meio de campo” para fazer a checagem entre os principals e serviço de autenticação, o kerberos sozinho não autentica nínguem, ele precisa do servidor de autenticação ou base de usuário. Uma observação importante é possivel fazer o kerberos autenticar utilizando sua própria base o que não é muito utilizado. O “meio de campo” utilizado pelo kerberos para interfacear principal e base de dados se chama KDC (Key Distribution Center ­ Centro de Distribuição de Chaves), responsável pela validação da identidade dos principals em conjunto com os serviços kerberizados. No processo de validação e criado uma chave secreta o qual é gerada utilizando a senha do usuário como item obrigatorio.

O KDC armazena a base de dados de principal e suas chaves, que são utilizadas para autenticação.

Vamos descrever alguns conceitos da estrutura kerberos:

• realm: Um reino ou realm kerberos é um grupo de computadores que compartilham informações contidas numa base de dados de autenticação ou kerberos e fazem uso do KDC.  O reino possui um nome que o identifica e, geralmente, é o mesmo nome do
  domínio DNS, porém em letras maiúsculas. Apesar dessa característica não ser
  obrigatória, ela tem sido comumente usada nas implementações do Kerberos.
• Principal: Como dito anteriormente o principal é qualquer item que pode fazer uso do kerberos ou ser autenticada. Isso inclui usuários, hosts e serviços de rede. Cada principal possui uma chave secreta o qual é constituida pela sua própria senha. Com isso o KDC e o principal conhecem essa chave.
  O principal é formado por três partes:
  • primário ­ é a primeira parte do principal. Pode ser o nome de um usuário ou serviço. Para um servidor é a palavra host.
  • instância ­ serve para qualificar o primário. É uma palavra que vem antes do principal separado por uma barra (/). Após a barra posso ter termos diferentes, são eles:
  1. Usuário: Após a barra teremos o usuario e sua credencial
  2. Host: Após a barra teremos o nome dns deste host.
  3. reino ou realm: Parte do nome do principal que indica o reino do principal

  Um exemplo de um principal seria: primário/instância@REINO. Para um principal de usuário seria:

  ricardobarbosa@YAMAHA.CORP
  ricardobarbosa/administrator@YAMAHA.CORP

  onde a palavra “administrator” indica que o principal tem privilégios administrativos no Kerberos.

  Exemplo de principais de serviços ou host a parte que seria o primário indica o serviço, um exemplo:

  HTTP/firewall.yamaha.corp@YAMAHA.CORP
  FTP/ftp.yamaha.corp@YAMAHA.CORP

  Se o nome do reino não for informado será usado como o reino padrão do contexto, isso no arquivo de configuração do kerberos ou seja /etc/krb5.conf.

Bom já que falamos demais poderiamos agora ter um pouco de ação ou quase isso fazer um teste de mesa e mostrar o passo a passo da conexão kerberos. Para isso imaginei o seguinte ambiente.

1 – Neste exemplo a estação com serviço de login kerberizado faz um request para o KDC solicitando um TGT.

2 – O KDC recebe o request e busca pelo principal da conexão na base de dados Kerberos ou seja no Active Directory, se o principal existe, o KDC pega a chave secreta do principal gerada com a senha do principal. Com isso ele irá gerar a chave de sessão e o TGT.  Nesse momento o KDC tem a chave secreta do principal, a chave de sessão e o TGT, blz, o KDC nesse momento criptografa o TGT com uma chave que somente ele KDC conhece. Nesse momento eu tenho o TGT criptografado com senha que somente o KDC conhece e a chave de sessão, após isso o KDC criptografa esse dois itens com a chave do usuário e o envia para o mesmo.

3 – Ao receber essa resposta, o cliente (kinit ou login) solicita a senha ao usuário e após a digitação da senha ela é convertida na chave secreta do usuário.

Essa chave é, então, utilizada para descriptografar a mensagem recebida do KDC, que contém a chave de sessão e o TGT
(criptografado pela chave do KDC). Perceba que a senha do usuário nunca foi para o meio somente nos endpoint no caso KDC e cliente. Vamos a um outro conceito para continuar nosso raciocínio.

O arquivo keytab

Cada usuario na base de dados possui uma senha, assim como cada serviço possue uma chave, onde esta chave e conhecida apenas pelo KDC e o próprio principal

No KDC essa chave e armazenada na base de dados. Agora no servidor que esta sendo executado o serviço as chaves são armazenadas localmente em tabelas em arquivos conhecidos como arquivos keytab. O serviço kerberizado utiliza o arquivo keytab da mesma forma que um usuário informa sua senha no ato de login. Quando o serviço precisa se autenticar ele utilizar a senha armazenada no arquivo keytab para se autenticar.

Utilizando o serviço kerberizado.

Para utilizar o serviço kerberizado e necessário o arquivo keytab no servidor onde roda o serviço. Vamos imaginar outro ambiente o qual será o foco do nosso post. Tenho o mesmo ambiente anterior mas agora tenho o Active Directory e KDC no mesmo servidor é o que existe na vida real o AD da microsoft já tem o kerberos embutido. Bom acrescentaremos o nosso servidor proxy mas especificamente squid veja o diagrama abaixo.

O cliente no navegador fará acesso a internet através do proxy que tem o serviço “HTTP”. O navegador verifica se no cache existe um ticket para acesso ao serviço solicitado. Se não existir, envia ao KDC uma solicitação de acesso ao serviço, ou seja envia um request solicitando um TGS(Ticket Granting Service) a partir do TGT.

1 – O navegador envia ao KDC o TGT a mensagem de solicitação TGS além de informação de horário(timestamp), criptografado com a chave de sessão que ele recebeu na conexão anterior. (lembra que tinha o TGT e a chave de sessão, esta chave e para uso apenas nas conexoes cliente e KDC).

2 – O KDC recebe descriptografa e obtém o TGT(criptografado com a chave conhecida apenas pelo KDC), com isso ele descriptografa o TGT com sua chave secreta e usando a chave de sessão descriptografa a mensagem de horário(timestamp). Presumindo que o KDC obteve exito nesse passos ele assume que o usuário é quem diz ser.

3 – O KDC gera então uma nova chave de sessão esta para ser usado entre servidor Proxy e cliente, cria um novo ticket (TGS) contendo a nova chave de sessão e identificação de usuário. Logo em seguida criptografa com a chave secreta do servidor a mesma chave que esta no keytab local . O KDC também criptografa a nova chave de sessão para ser usada entre servidor e cliente utilizando a primeira chave de sessão que deve ser usada somente entre KDC e cliente( E chave pra caramba né ).

4 – O novo ticket criptografado com a chave do servidor ( a mesma do keytab) e a nova chave de sessão criptografada( a chave para ser usada entre proxy e cliente) com a chave de sessão do usuário( a chave que deve ser usada entre KDC e cliente) são enviados ao usuário.

5 – O cliente recebe o ticket (TGS) e a chave de sessão (para ser usada entre proxy e cliente) enviados pelo KDC, descriptografa a chave de sessão (criptografada pela chave de sessão, aquela usada entre KDC e cliente lembra foi enviada a chave de sessão entre proxy e cliente criptografada com esta chave) e logo em seguida armazena ambas as chaves no cache de credenciais. Ele usa a nova chave de sessão( a que deve ser usado entre proxy e cliente) para criptografar uma mensagem, e envia ao servidor proxy juntamente TGS.

6 – O servidor recebe o pacote e de posse da chave secreta dele mesmo(Aquela que está no arquivo keytab o qual está segura no disco local ) e a usa para descriptografar o ticket (TGS) recebido do usuário, tendo acesso, portanto, à identidade do usuário e à chave de sessão (aquela que foi criada para ser usada entre proxy e cliente não a chave que foi criada para ser usada entre KDC e cliente ) . Com essa chave de sessão o servidor abre a mensagem recebida do cliente, com isso automaticamente autentica o usuário.

7 – Após isso se o usuário tem permissão para navegar em determinada URL o acesso e concedido senão negado. Nesse ponto ambos tanto cliente como servidor proxy  têem a chave de sessão criada pelo KDC para comunicação entre eles, e podem utilizá-la para criptografar o tráfego entre eles.

Veja que a comunicação fluiu sem em um único momento a senha ir para a rede e para deixar mais seguro se alguém conseguir interceptar os tickets e chave de sessão ainda temos o tempo de expiração que deixará inutil a chave

Bom agora depois de teoria e explicações ao meu ver satisfatoria vamos a implantação e configuração criei um ambiente de exemplo tenho isso em produção em vários clientes e funciona muito bem. Antes de continuar quero deixar claro que kerberos não envolve somente nisso que expliquei acima a coisa flue da forma que disse mas existe muito detalhes que não abortei aqui para não deixar extenso então se querem conhecer a fundo meu conselho apontem seus links para a página do MIT http://web.mit.edu/kerberos/.

Segue abaixo o ambiente de exemplo iremos utilizar os seguintes softwares e servidores

servidor proxy :
Softwares: squid 3.0, kerberos 5.0 versão clientes e config, squid_kerb_ldap um helper de autenticação para o squid desenvolvido pelo Markus Moeller, tive a oportunidade de trocar uma idéia com esse cara na lista squid-users e um cara muito gente boa e sanou várias dúvidas que tinha em relação ao squid_kerb_ldap.

Servidor KDC:
Softwares: Normalmente você ja deve ter isso na sua empresa ou na empresa que trabalha, tratasse do poderoso servidor de diretório da Microsoft – Active Directory e sim ele já possue um KDC embutido criado pela Microsoft ao contrário do que muitos pensam sim a Microsoft usa Software Livre, implementa e reimplementa e funciona muito bem

Cliente:
Como nosso ambiente é para sistemas Microsoft iremos utilizar qualquer estação que faça parte do domínio.

Segue mais alguns dados:

Dominio: YAMAHA.CORP
Servidor Proxy: 192.168.0.15
Servidor DC Windows 2008 R2: 192.168.0.8
Usuário do AD para criação do keytab: squid
Senha: 123456 ( e apenas para testes)

Vamos por a mão na massa inicialmente instalar o squid estou utilizando a distribuição Ubuntu.

[root@firewall root]# aptitute install squid3 krb5-config krb5-clients krb5-user libsasl2-modules-gssapi-mit

Depois vamos baixar o pacote squid_kerb_ldap no site http://squidkerbauth.sourceforge.net/.

Para compilar o squid_kerb_ldap iremos precisar do pacote de compilação do ubuntu e bibliotecas de desenvolvimento do kerberos

[root@firewall root]# aptitute install build-essential libkrb5-dev

Vamos compilar o squid_kerb_ldap.

[root@firewall root]# cd squid_kerb_ldap
[root@firewall root]# ./configure
[root@firewall root]# make

Após compilar será gerado um binário chamado “squid_kerb_ldap”, copie este binário para o caminho “/usr/lib/squid3/”, na instalação do squid já consta o squid_kerb_auth.

Vamos agora a configuração do squid para que ele passe a reconhecer usuários via kerberos.

auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/proxy.yamaha.local
auth_param negotiate children 10
auth_param negotiate keep_alive on

se for autenticar por usuários utilize

# acl que solicita autenticação para o usuário ricardo barbosa no caso eu
acl ricardobarbosa proxy_auth ricardobarbosa@YAMAHA.CORP
# Acl para dar match nos sites que serão permitidos
acl sites_liberados src “/etc/squid3/sites_liberados.cfg”

# permite o acesso as conexões autenticas via kerberos pelo usuário ricardo barbosa a sites_liberados
http_access allow ricardobarbosa sites_liberados

Se for por grupo utilize

# acl externa que utiliza squid_kerb_ldap
external_acl_type g_restrito ttl=3600 negative_ttl=3600 %LOGIN /usr/lib/squid3/squid_kerb_ldap -g G_restrito@YAMAHA.CORP
# Acl para dar match na acl externa
acl grupo_grestrito external g_restrito
# Acl para dar match nos sites que serão permitidos
acl sites_liberados src “/etc/squid3/sites_liberados.cfg”

# Permitindo o grupo restrito do AD ao lista de sites liberados
http_access allow grupo_gretrito sites_liberados

Agora e hora de gerar o arquivo keytab o windows possue um comando de linha que gera o keytab ai depois e somente necessário copiar para o servidor proxy, segue o comando abaixo.

c:\> ktpass -princ HTTP/proxy.yamaha.corp@YAMAHA.CORP -mapuser YAMAHA\squid -crypto All -mapop set -pass 123456 -ptype KRB5_NT_SRV_HST -out HTTP.keytab

E bem intuitivo vamos a cada item

• -princ HTTP/proxy.yamaha.corp@YAMAHA.CORP: Principal do servidor proxy, nós lembramos o que é principal senão lembra volte lá em cima no começo do tutorial e leia de novo
• -mapuser YAMAHA\squid: Nome do usuário que será gerado o keytab
• -crypto All: Será gerado o keytab com todas os algoritmos de criptografia que o KDC do AD suporta.
• -mapop set -pass 123456: Definindo a senha
• -ptype KRB5_NT_SRV_HST: Define que o tipo do principal no caso é um “host service instance”. Outras possiveis opção são:
  1. KRB5_NT_PRINCIPAL: Este o principal de uso geral.
  2. KRB5_NT_SRV_INST: É um instancia de serviço de usuário.
  3. KRB5_NT_SRV_HST: É uma instancia de serviço de host.
• -out HTTP.keytab: Nome do arquivo keytab gerado

No seguinte link tem mais informações sobre a ferramenta ktpass http://technet.microsoft.com/en-us/library/cc753771%28WS.10%29.aspx

Depois de keytab gerado copie o arquivo para o servidor Linux via ssh pscp te vira . Um detalhe quando você gera o keytab você não pode resetar a senha no meu caso do usuário squid se você fizer, vai invalidar o arquivo keytab e terá de gerar outro. Isso porque existe um campo no keytab que é chamado kvno que é simplesmente um acrônimo para “número da versão da chave” ou key version number. para ajudar
distinguir entre várias chaves associados com o mesmo principal (por
exemplo, se um usuário alterar sua senha), cada chave é associada a uma versão de chave. Números de versão-chave normalmente começam em zero quando o principal é criado pela primeira vez e são incrementados por um cada vez que a senha é alterada.

Para verificar o kvno do keytab utilize.

[root@firewall root]# kvno HTTP/proxy.yamaha.corp
HTTP/proxy.yamaha.corp@YAMAHA.CORP: kvno = 3
[root@firewall root]#

Para deixar esse “controle” do kvno automático você pode colocar o servidor proxy no domínio utilizando samba com kerberos, e utilizar o keytab a partir do samba ai seus problemas acabaram .

Para autenticar a partir do keytab utilize o comando.

[root@firewall root]# kinit -V -k -t /etc/krb5.keytab HTTP/proxy.yamaha.corp
Authenticated to Kerberos v5
[root@firewall root]#

Agora vamos testar navegar. Alguns navegadores não suportam autenticação kerberos é o caso do Safari e Opera. O Internet Explorer e Firefox funciona nativamente, o IE precisa a opção “autenticação integrada do windows” estar marcada dentro da aba avançado dentro de propriedades de internet o que já vem padrão.

1318895606.294 224 172.31.1.51 TCP_MISS/204 674 GET http://www.google.com.br/csi? thor@YAMAHA.CORP DIRECT/74.125.91.106 image/gif
1318895671.192 672 172.31.1.51 TCP_MISS/200 15648 GET http://www.google.com.br/ aquaman@YAMAHA.CORP DIRECT/74.125.91.104 text/html
1318895672.040 264 172.31.1.51 TCP_MISS/204 391 GET http://www.google.com.br/csi? kakaroto@YAMAHA.CORP DIRECT/74.125.91.104 image/gif
1318895695.747 0 172.31.1.51 TCP_DENIED/407 3222 GET http://www.google.com.br/search? – NONE/- text/html
1318895696.402 507 172.31.1.51 TCP_MISS/200 13464 GET http://www.google.com.br/search? ironman@YAMAHA.CORP DIRECT/74.125.91.104 text/html
1318895696.845 0 172.31.1.51 TCP_DENIED/407 3140 GET http://www.google.com.br/csi? – NONE/- text/html
1318895697.426 421 172.31.1.51 TCP_MISS/204 674 GET http://www.google.com.br/csi? hulk@YAMAHA.CORP DIRECT/74.125.91.99 image/gif
1318895718.361 0 172.31.1.51 TCP_DENIED/407 3027 GET http://www.google.com.br/url? – NONE/- text/html
1318895718.636 262 172.31.1.51 TCP_MISS/302 1009 GET http://www.google.com.br/url? spiderman@YAMAHA.CORP DIRECT/74.125.91.99 text/html
1318895723.604 0 172.31.1.51 TCP_DENIED/407 3019 GET http://www.google.com.br/url? – NONE/- text/html
1318895723.908 292 172.31.1.51 TCP_MISS/302 993 GET http://www.google.com.br/url? superman@YAMAHA.CORP DIRECT/74.125.91.99 text/html
1318895724.972 414 172.31.1.51 TCP_MISS/200 13980 GET http://www.google.com.br/search? batman@YAMAHA.CORP DIRECT/74.125.91.99 text/html
1318895725.115 0 172.31.1.51 TCP_DENIED/407 3140 GET http://www.google.com.br/csi? – NONE/- text/html
1318895725.572 421 172.31.1.51 TCP_MISS/204 674 GET http://www.google.com.br/csi? ricardobarbosa@YAMAHA.CORP DIRECT/74.125.91.105 image/gif

Parece que este servidor de proxy e da liga da justiça ou o QG dos superheróis .

Até a próxima qualquer dúvida post uma pergunta.

Preciso redirecionar 2 porta externas distintas para a mesma porta interna, ou seja, redirecionar tudo que chega na porta 80 e 8080 no ip outside 200.200.200.200 para o endereço ip interno 192.168.10.10 na mesma porta 80. A principio isso e fácil criamos 2 nat estaticos conforme abaixo

static(inside, outside) tcp 200.200.200.200 80 192.168.10.10 80 netmask 255.255.255.255
static(inside, outside) tcp 200.200.200.200 8080 192.168.10.10 80 netmask 255.255.255.255

Mas esta solução não ira funcionar, a primeira regra irá funcionar sem problemas, mas quando inserir a segunda regra ele irá reclamar dizendo que já existe uma regra de nat estatico para a porta 80 e o que fazer então?

Vamos trabalhar com access-list. Criaremos 2 access-list’s

access-list policy1 permit tcp host 192.168.10.10 eq 80 any
access-list policy2 permit tcp host 192.168.10.10 eq 80 any

static (inside,outside) tcp 200.200.200.200 80 access-list policy1
static (inside,outside) tcp 200.200.200.200 8080 access-list policy2

Simples né.

Att.

Introdução

Em ocasiões frequentemente depois de um ataque, podemos encontrar em nossos servidores binarios ou executaveis misteriosos. Programas que podem ter sido usado por um hacker para comprometer sua rede ou servidor.
Pode-se utilizar técnicas e métodos juntamente com ferramentas para fornece pistas do que o programa suspeito faz.

Como saber o tipo de arquivo?

Para obter informação do tipo do arquivo e muito simples e fácil utilizamos um software para isso o comando “file”. veja um exemplo de uso do mesmo:

root@capsula:~# file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
root@capsula:~# file mkdosfs
/sbin/mkdosfs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, statically linked, not stripped
root@capsula:~#

Um item interessante à analisar nos 2 binarios é que o comando “ls” esta construindo com links dinamicos enquanto o comando “mkdosfs” esta construido estaticamente. Por padrão o compilador gcc constroi o aplicativo dinamicamente. Este comportamento pode ser alterado através do flag -static. Com isso deixando o binario sem a dependência de libs externas porém deixando o arquivo maior.

Fiz um “hello world” em C para demostrar isso. Segue abaixo o exemplo.

root@capsula:~/dev# gcc teste.c -o dinamic
root@capsula:~/dev# gcc -static teste.c -o static
root@capsula:~/dev# ls -lh
total 744K
-rwxr-xr-x 1 root root 8.3K 2010-10-07 21:46 dinamic
-rwxr-xr-x 1 root root 725K 2010-10-07 21:46 static
-rw-r–r– 1 root root 71 2010-10-07 21:46 teste.c
root@capsula:~/dev#

Vejam a diferença entre os tamanhos do binario compilado statico e dinamico. Outro item a se averiguar e a string “stripped” e “not stripped”, afinal o que quer dizer isso?
Um binario “stripped” significa que o mesmo não possue os símbolos do arquivo objeto. Simbolos que são gerados pelo compilador e ajudam na busca de informaçoes sobre o binário analisado.

Um hacker pode eliminar os simbolos do binário através do comando “strip”.

root@capsula:~/dev# ls -lh static
-rwxr-xr-x 1 root root 725K 2010-10-07 21:46 static
root@capsula:~/dev# strip static
root@capsula:~/dev# ls -lh static
-rwxr-xr-x 1 root root 650K 2010-10-07 21:51 static
root@capsula:~/dev#

Repare no exemplo acima que o tamanho do binario diminui, legal neh

Bom digamos que o hacker esqueceu de sumir com os símbolos do binario, podemos analisá-los entao. Existe um comando que nos auxilia nessa tarefa o comando “nm”, ele lista os simbolos do binario.

root@capsula:~/dev# nm static
nm: static: no symbols
root@capsula:~/dev#

Mas se analisarmos o binário compilado “dinamic” será que ele possue simbolos?

root@capsula:~/dev# nm dinamic
0000000000600e40 d _DYNAMIC
0000000000600fe8 d _GLOBAL_OFFSET_TABLE_
0000000000400638 R _IO_stdin_used
w _Jv_RegisterClasses
0000000000600e20 d __CTOR_END__
0000000000600e18 d __CTOR_LIST__
0000000000600e30 D __DTOR_END__
0000000000600e28 d __DTOR_LIST__
00000000004006e8 r __FRAME_END__
0000000000600e38 d __JCR_END__
0000000000600e38 d __JCR_LIST__
0000000000601020 A __bss_start
0000000000601010 D __data_start
00000000004005f0 t __do_global_ctors_aux
0000000000400490 t __do_global_dtors_aux
0000000000601018 D __dso_handle
w __gmon_start__
0000000000600e14 d __init_array_end
0000000000600e14 d __init_array_start
0000000000400550 T __libc_csu_fini
0000000000400560 T __libc_csu_init
U __libc_start_main@@GLIBC_2.2.5
0000000000601020 A _edata
0000000000601030 A _end
0000000000400628 T _fini
00000000004003f0 T _init
0000000000400440 T _start
000000000040046c t call_gmon_start
0000000000601020 b completed.7382
0000000000601010 W data_start
0000000000601028 b dtor_idx.7384
0000000000400500 t frame_dummy
0000000000400524 T main
U printf@@GLIBC_2.2.5
root@capsula:~/dev#

Sim e bastante

Note que nosso binário não faz nada demais apenas usa a função “printf”, mas olhe bem no final do comando “nm”. Vemos um “printf”, como funcionou para visualizar o acesso a função “printf”, funciona para outras chamadas de sistemas como “socket”, “connect”, “ioctl”, etc.

Olhando dentro do executável

Existe um comando que nos permite olhar em até certa parte dentro de um executável. O comando ‘strings’ ele permite obter os textos de caracteres armazenado no executável. Vejamos um exemplo:

root@capsula:~/dev# strings dinamic
/lib64/ld-linux-x86-64.so.2
__gmon_start__
libc.so.6
printf
__libc_start_main
GLIBC_2.2.5
fff.
=/
fffff.
l$ L
t$(L
|$0H
Hello World
root@capsula:~/dev#

Veja bem no final o conteudo do nosso printf “hello world”. Se estiver analisando um binário misterioso com esse comando você obter detalhes da função “printf” ou qualquer outra cadeia de caracteres que o binário misterioso faz uso.

Análise dinâmica.

Apos analisarmos o binario e verificar que não oferece perigo podemos executá-lo e analisar quais chamadas de sistemas e bibliotecas que ele chama ou executa.
Possuimos 2 comandos para isso, são eles:

strace – Permite visualizar as chamadas de sistemas que são executadas pelo binário.
ltrace – Permite visualizar as bibliotecas executadas pelo binário.

strace

root@capsula:~/dev# strace ./dinamic
execve(“./dinamic”, ["./dinamic"], [/* 20 vars */]) = 0
brk(0) = 0×1128000
access(“/etc/ld.so.nohwcap”, F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe5c153000
access(“/etc/ld.so.preload”, R_OK) = -1 ENOENT (No such file or directory)
open(“/etc/ld.so.cache”, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=17219, …}) = 0
mmap(NULL, 17219, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbe5c14e000
close(3) = 0
access(“/etc/ld.so.nohwcap”, F_OK) = -1 ENOENT (No such file or directory)
open(“/lib/libc.so.6″, O_RDONLY) = 3
read(3, “\177ELF\2\1\1\3>\1`\355\1″…, 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1572232, …}) = 0
mmap(NULL, 3680296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbe5bbb2000
mprotect(0x7fbe5bd2c000, 2093056, PROT_NONE) = 0
mmap(0x7fbe5bf2b000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0×179000) = 0x7fbe5bf2b000
mmap(0x7fbe5bf30000, 18472, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbe5bf30000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe5c14d000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe5c14c000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe5c14b000
arch_prctl(ARCH_SET_FS, 0x7fbe5c14c700) = 0
mprotect(0x7fbe5bf2b000, 16384, PROT_READ) = 0
mprotect(0×600000, 4096, PROT_READ) = 0
mprotect(0x7fbe5c155000, 4096, PROT_READ) = 0
munmap(0x7fbe5c14e000, 17219) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), …}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe5c152000
write(1, “Hello World”, 11Hello World) = 11
exit_group(0) = ?
root@capsula:~/dev#

ltrace

root@capsula:~/dev# ltrace ./dinamic
__libc_start_main(0×400524, 1, 0x7fff6d162488, 0×400560, 0×400550
printf(“Hello World”) = 11
Hello World+++ exited (status 0) +++
root@capsula:~/dev#

Note que o nosso softwarezinho de exemplo chama um certo número de chamadas e apenas executa a função “printf”, presente na biblioteca stdio.h ou libc conforme a string indica “__libc_start_main”.

Bom espero ter conseguido demostrar algumas formas de analisar arquivos executáveis ou binários. E espero daqui para frente ter tempo para postar.

Att.

Figura tirada do site http://forum.rodao.com.br/forum/viewthread.php?forum_id=17&thread_id=442

Atenciosamente.

Você certamente deve conhecer vários profissionais com diferentes capacidades e características. Cada um tem seus pontos fortes e fracos do mundo corporativo. A seguir você encontra um guia rápido para identificar esses seres, com a peculiaridades de cada um.

Wolverine

Os professionais wolverine são selvagens e muito obstinados, porém parte para ação sem pensar ou planejar muito.

Pontos fortes

-Encaram qualquer desafio.
-Não descansam enquanto não cumprem o objetivo desejado.
-Não temem o fracasso.
-Recuperam-se rápido das ações malsucedidas.

Pontos fracos
-Não planejam.
-Agem intuitivamente.
-Possuem falta de diplomacia.

Batman

Esses profissionais fazem o tipo silencioso, porém são sábios e observadore. Preferem pensar muito e nunca parte para a ação sem um plano bem traçado.

Pontos fortes
-São planejadores habeis.
-Sempre tem um plano B.
Observadores e atentos, sempre sabem o que está ocorrendo a sua volta.

Pontos fracos
-Silenciosos, não vendem muito bem, o que prejudica sua imagem
-Tendem a não delegar tarefas.

Superman

São diplomáticos e extremamentes altruistas. Ótimos líderes e capazes de fazer legiões inteiras o seguirem.

Pontos fortes
-São persuasivas e carismáticas ao extremo.
-Educados e comunicativos, vendem-se muito bem.
-Pólidos e diplomáticos, resolvem as situações sem brigas ou extresse.

Pontos fracos
-Por pensarem demais nos outros, acabam absorvendo problemas que não deveriam.
-Por terem uma imagem de muito bonzinhos, os outros tiram vantagem disso.

Mulher maravilha

Essa é a incansável e guerreira que vive no mundo do patriarcado, em que precisa , além de provar todo o seu valor na luta cotidiana, trabalhar o dobro para ter o mesmo reconhecimento dados aos homens.

Pontos fortes
-Inteligência emocional.
-Determinação.
-Visão perférica(vê tudo o que esta acontecendo ao seu redor).

pontos fracos
-Descontrole emocional (em alguns dias do mês).
-Jornada dupla(trabalha fora e ainda cuida da casa) causa fadiga.

Homem Aranha

Este é o tipo que vive pendurado pelo teto. Muitos jovens, porém fiéis e dedicados, esses profissionais tem várias ocupações, dividindo a atenção com diversos trabalhos e tentando(ainda que em vão) levar uma vida pessoal regular.

Pontos fortes
-São dedicados e esforçados e fiéis.
-Agéis e flexíveis, tem grande capacidade de adaptação a várias funções.

Pontos fracos
-Ainda imaturos, muitas vezes cometem deslizes que comprometem um melhor resultado.
-Vivem cansados por não focarem suas tarefas ou não souberem dividir o tempo.

Esse erro e contornavel. Primeiro obtenha uma cópia do arquivo system.dll de uma máquina windows 7 com .NET versão 3.5 SP1 instalado, ou obtenha direto do link abaixo http://www.4shared.com/file/254124783/2cdd7844/system.html. Crie uma pasta no caminho de instalacao do vsphere client normalmente em “%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib”. No mesmo diretório edite o arquivo “VpxClient.exe.config” e adicione o seguinte trecho, abaixo da string “” salve o arquivo e tente abrir o vsphere

<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<system.net>
<connectionManagement>
<clear/>
<add address=”*” maxconnection=”8″ />
</connectionManagement>
</system.net>
<appSettings>
<add key = “protocolports” value = “https:443″/>
</appSettings>
<runtime>
<developmentMode developerInstallation=”true”/>
</runtime>
</configuration>

Após coloque o caminho “%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib” na variável de ambiente path.

Agora tente abrir o vsphere client que irá funcionar. Comigo funcionou

Att.

Então resolvi falar um pouco sobre algumas formas que o postfix trabalha.  Vamos lá

Arroz com feijão

O feijão com arroz do postfix é bem simples iremos configurar um servidor de e-mail respondendo a um único dominio apenas. No nosso exemplo o dominio será yamaha.com.br. Será usada essa mesma configuração para todos os ambientes posteriores de teste que utilizaremos.

Dominio: yamaha.com.br
SMTP: mail.yamaha.com.br
Endereço IP: 192.168.1.10/24

Segue topologia abaixo:


myhostname = mail.yamaha.com.br
mydomain = yamaha.com.br
mydestination = localhost, yamaha.com.br


Vamos la o primeiro parametro é o “myhostname” o qual é o nome do host que esta instalado o servidor de e-mail, ou seja o MTA(MTA e o servidor de e-mail proprieamente dito) no nosso caso configuramos o nome do servidor de e-mail como “mail.yamaha.com.br” um nome ficticio.
O segundo parametro é o “mydomain” que indica o nome do domínio que o servidor de e-mail(postfix) acomoda.
O terceiro parametro “mydestination” e muito importante ele que diz quais dominios o servidor de e-mail ira atender, no caso yamaha.com.br, entao sendo assim todos os emails destinados ao user@yamaha.com.br deverá ser entregue ao nosso servidor com endereço ip 192.168.1.10 ou mail.yamaha.com.br qualquer outra coisa por exemplo user@honda.com.br será rejeitado com a mensagem nos logs “user unknown”.

Funcionamento

O usuário na estação workstation envia um email apartir de fulano@yamaha.com.br para ciclano@yamaha.com.br, para esse envio funcionar os usuarios fulano e ciclano devem existir no /etc/passwd. Outro exemplo o fulano@honda.com.br envia e-mail para ciclano@yamaha.com.br o mta do dominio honda ira consultar o registro MX do dominio yamaha.com.br no servidor dns responsavel pelo dominio no caso ns1.yamaha.com.br o qual irá responder mail.yamaha.com.br, assim sendo o cliente fulano@honda.com.br envia outro pedido para resolucao de endereço ip do nome mail.yamaha.com.br para somente entao enviar o email para ciclano@yamaha.com.br. Quando o postfix receber o pacote de dados ira checar se existe o usuario ciclano no /etc/passwd e entregar a mensagem. Esse e o hello world em postfix

Preparando os ingredientes

Blz funcionou o ambiente com um único dominio, mas se eu precisar de que um postfix atender a mais de um dominio. Por exemplo yamaha.com.br e honda.com.br? para isso vou utilizar o virtual domain do postfix. Postfix pode enviar, receber e armazenar mensagem para mais de um dominio usando dois métodos.

• virtual_alias_domains
• virtual_mailbox_domains

O primeiro método virtual_alias_domains expande o número de dominios para o qual o servidor postfix é o destino final. Os dominios listados no parametro “mydestination” são chamados de dominios canonicos porque normalmente listão todas os domínios da máquina local. Para ter dominios a mais ou seja sem o dominio ser local é preciso criar um virtual_alias_domains. Por exemplo no exemplo anterior nos tinhamos o base de usuarios de email ficava no /etc/passwd e atendia pelo dominio yamaha.com.br, porém imaginemos que acontece aquelas fusões de grandes empresas e a yamaha comprasse a honda. Entao teriamos que ter alguns usuarios com o dominio yamaha.com.br e o dominio honda, dessa forma teriamos o usuário fulano como fulano@yamaha.com.br e fulano@honda.com.br na mesma máquina. Utilizando a configuração anterior poderiamos ter esse ambiente utilizando virtual_alias_domains. Um alias e um apelido logo um alias_domains e um apelido para o dominio no caso o dominio local se chama yamaha.com.br e o apelido seria honda.com.br. Esse apelido pode ser para a mesma conta de usuario, mailbox ou para conta de usuario distinta, outra mailbox. Segue nova configuração abaixo.

myhostname = mail.yamaha.com.br
mydomain = yamaha.com.br
mydestination = localhost, yamaha.com.br
virtual_alias_domains = honda.com.br
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps


Veja o arquivo “/etc/postfix/virtual_alias_maps”.


# honda.com.br
postmaster@honda.com.br postmaster@yamaha.com.br
jaspion@honda.com.br jaspion@yamaha.com.br
batman@honda.com.br bruce@yamaha.com.br
bruce@honda.com.br bruce@yamaha.com.br


Espaguete

Vamos testar o envio de mensagem.


# echo test | sendmail bruce@honda.com.br
ou
# mail -s test bruce@honda.com.br


Vejam os logs do envio do e-mail.


Mar 26 08:28:04 mail postfix/qmgr[5224]: C8FDBF292:
from=<root@yamaha.com.br>, size=1266, nrcpt=1 (queue active)
Mar 26 08:28:04 mail postfix/smtpd[5230]: disconnect from
localhost[127.0.0.1]
Mar 26 08:28:04 mail postfix/local[5226]: C8FDBF292:
to=<bruce@honda.com.br>, relay=local, delay=0.02,
delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (delivered to mailbox)


Vemos nas partes em negrito a origem(quem enviou o e-mail) e o destino do e-mail no caso root@yamaha.com.br(from) e bruce@honda.com.br(to).

Rocambolé de carne

O próximo método de virtual domain é o virtual_mailbox_domains, um virtual_mailbox_domains são domínios para os usuários que não têm uma conta local (isto é, para os usuários que não estão no arquivo /etc/passwd). Existe um agente de entrega(delivery agent): virtual e local. Por padrão o postfix utiliza o agente local o agente de entrega virtual(virtual delivery agent) não pode acessar seu sistema de usuário local(/etc/passwd) para procurar os nomes dos destinatários. Em vez disso, o agente de distribuição virtual depende inteiramente de mapa que não têm nada a ver com o seu sistema informados na configuração(virtual_mailbox_maps, virtual_mailbox_aliases). Segue abaixo uma configuração utilizando virtual_mailbox_*.


myhostname = mail.yamaha.com.br
mydomain = yamaha.com.br
mydestination = localhost.$mydomain, $myhostname
mynetworks = 127.0.0.0/8, 192.168.0.0/16, 10.1.4.0/24, 10.0.0.0/24
virtual_mailbox_domains = honda.com.br
virtual_uid_maps = static:2001
virtual_gid_maps = static:1001
virtual_mailbox_base = /maildir
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_recipients
virtual_alias_maps = hash:/etc/postfix/virtual_mailbox_aliases


Arquivo “/etc/postfix/virtual_mailbox_recipients”.


batman@honda.com.br batman/
robin@honda.com.br robin/
aquaman@honda.com.br aquaman/
superman@honda.com.br superman/
flash@honda.com.br flash/


O caracter “/” indica que a mailbox está no formato maildir não mais em mailbox, que é o padrão do postfix. Arquivo “/etc/postfix/virtual_mailbox_aliases”


bruce@honda.com.br batman@honda.com.br
dick@honda.com.br robin@honda.com.br
clark@honda.com.br superman@honda.com.br
barry@honda.com.br flash@honda.com.br


Vamos testar o envio de mensagem.


# echo test | sendmail bruce@honda.com.br
ou
# mail -s test bruce@honda.com.br


Vejam os logs do envio do e-mail.


Mar 26 08:28:04 mail postfix/qmgr[5224]: C8FDBF292:
from=<root@yamaha.com.br>, size=1266, nrcpt=1 (queue active)
Mar 26 08:28:04 mail postfix/smtpd[5230]: disconnect from
localhost[127.0.0.1]
Mar 26 08:28:07 mail postfix/local[5226]: CE83BF287:
to=<batman@honda.com.br>, orig_to=<bruce@honda.com.br>,
relay=local, delay=0.24, delays=0.01/0/0/0.24, dsn=2.0.0, status=sent
(delivered to maildir)


Lembrando que toda essa configuração ocorreu sem autenticação e apenas para ilustrar e elucidar os conceitos de virtual_alias e virtual_mailbox que quando comecei a mexer com postfix achei muito confuso e não vi uma documentação explicando apenas receitas de bolos.

Att.

Bom para criar um lkm voce precisa de pre-requisitos um deles é saber a melhor linguagem de todos os tempos “C” sendo assim eu vou pressupor que voce leitor ja é um programador C. Segue codigo abaixo do nosso LKM.


/*
* hello_world.c - Um simples LKM.
*/
#include <linux/module.h> /* cabeçalhos requeridos */
#include <linux/kernel.h>

int init_module(void)
{
printk(KERN_INFO "Hello world 1.\n");
return 0;
}

void cleanup_module(void)
{
printk(KERN_INFO "Goodbye world 1.\n");
}


Vamos as explicações? Pois bem as primeiras linhas e bem intuitivo declaracao de bilbliotecas do kernel. Na linha:


int init_module(void)
{
printk(KERN_INFO "Hello world 1.\n");
return 0;
}


E a função responsavél por inicializar nosso módulo ou seja carrega nosso código dentro do espaço kernel, vamos fazer uma parada aqui. Afinal o que é espaço kernel? Bom uma regra, todo LKM e executado no assim chamado “espaço kernel” ou “kernel space” enquanto que aplicativos como o editor vim, openoffice, firefox rodam em “espaço usuário” ou “user space”. Livro do Tannenbaum função de um sistema operacional é a de criar programas ou softwares para serem executados em um computador e criar uma interface para esses programas ou softwares protegendo o acesso nao autorizado a dispositivos de hardware e software tirando assim a responsabilidade do programador de aplicativos de se preocupar em carregar registradores da CPU chamar interrupção tal, etc. Esse “espaço” assim designado e chamado de espaço kernel e cria essa proteção dos softwares de usuários do sistema operacional. Bom agora que sabemos o que é espaço kernel e espaço usuário continuamos analisando o código.


void cleanup_module(void)
{
printk(KERN_INFO "Goodbye world 1.\n");
}


Como temos a função de entrada no kernel(kernel space), também temos a função de saida do kernel “cleanup_module” simples né. Agora vamos a função dentro de cada item(init e cleanup) os “printk”. Quem e acostumado ou é programador C já sacou o que faz o printk sim ele e equivalente ao printf no espaço usuário porém com resalvas. A macro “KERN_INFO” é uma macro que indica prioridade para a mensagem via printk normalmente utilizado pelo ksyslog ou klogd em sistemas Linux antigos. Com isso você pode definir prioridade quando for definir mensagem para o programador do kernel. Existem 8 niveis de prioridade definidas no arquivo de cabeçalho kernel.h normalmente nos fontes do kernel fica em linux-versao/include/linux/kernel.h, vejam as prioridades abaixo.


#define KERN_EMERG "" /* system is unusable */
#define KERN_ALERT "" /* action must be taken immediately */
#define KERN_CRIT "" /* critical conditions */
#define KERN_ERR "" /* error conditions */
#define KERN_WARNING "" /* warning conditions */
#define KERN_NOTICE "" /* normal but significant condition */
#define KERN_INFO "" /* informational */
#define KERN_DEBUG "" /* debug-level messages */


Blz código explicado vamos compilar, mas antes precisamos criar um arquivo Makefile para ser utilizado pela ferramenta de compilação make. Segue Makefile abaixo:


obj-m += hello_world.o

all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean


Não é intuito deste post explicar o funcionamento do make senão o post vai ficar muito extenso talvez num post futuro. Após a criacao do arquivo execute o comando make


root@capsula:~/lkm# ls
hello_world.c Makefile
root@capsula:~/lkm#
root@capsula:~/lkm# make
make -C /lib/modules/2.6.31-14-generic-pae/build M=/home/ricardobarbosa/lkm modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.31-14-generic-pae'
CC [M] /home/ricardobarbosa/lkm/hello_world.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/ricardobarbosa/lkm/hello_world.mod.o
LD [M] /home/ricardobarbosa/lkm/hello_world.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.31-14-generic-pae'
root@capsula:~/lkm# ls
hello_world.c hello_world.mod.c hello_world.o Module.markers Module.symvers
hello_world.ko hello_world.mod.o Makefile modules.order
root@capsula:~/lkm#


Ótimo meu módulo compilou com sucesso e podemos ver o modulo .ko (uma curiosidade sabe oque significa a extensao .ko – Kernel Object). Vamos subir nosso módulo dentro do kernel? para isso utilizamos o comando insmod (utilitário para carregamento e descarregamento de lkm).


root@capsula:~/lkm# modinfo hello_world.ko
filename: hello_world.ko
srcversion: 140276773A3090F6F33891F
depends:
vermagic: 2.6.31-14-generic-pae SMP mod_unload modversions 586
root@capsula:~/lkm# insmod hello_world.ko
root@capsula:~/lkm# lsmod
Module Size Used by
hello_world 988 0
crc_ccitt 1852 1 dahdi
iptable_filter 3100 0
ip_tables 11692 1 iptable_filter
x_tables 16544 1 ip_tables
snd_intel8x0 30168 0
snd_ac97_codec 101216 1 snd_intel8x0
ppdev 6688 0
ac97_bus 1532 1 snd_ac97_codec
psmouse 56180 0
snd_pcm 75488 2 snd_intel8x0,snd_ac97_codec
serio_raw 5280 0
snd_timer 22276 1 snd_pcm
lp 8964 0
i2c_piix4 10124 0
snd 59204 4 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
parport_pc 32228 0
soundcore 7264 1 snd
snd_page_alloc 9252 2 snd_intel8x0,snd_pcm
parport 35340 3 ppdev,lp,parport_pc
pcnet32 33156 0
mii 5212 1 pcnet32
floppy 54980 0
root@capsula:~/lkm#


Blz nosso lkm subiu sem erro e podemos ver ele carregado quando executamos o comando lsmod(list modules). Subimos o módulo e como sabemos se o nosso módulo funcionou?? Para isso iremos usar o comando dmesg utilitário que exibe as mensagens de inicialização e vindas do kernel.


root@capsula:~/lkm#
.....
[ 105.300548] eth0: link up, 100Mbps, full-duplex
[ 115.782079] eth0: no IPv6 routers present
[13593.784665] hello_world: module license 'unspecified' taints kernel.
[13593.785548] Disabling lock debugging due to kernel taint
[13593.785716] Hello world 1.
root@capsula:~/lkm#


Notem a mensagem hello world nosso módulo subiu perfeitamente notem tambem a mensagem “hello_world: module license ‘unspecified’ taints kernel.” isso é uma forma de indicar que nosso módulo foi inserido no kernel sem uma declaração de licença explicita, o que falta é uma declaração da licença usada pelo módulo. Para isso usamos a macro.


MODULE_LICENSE("GPL");


Adicione o código acima ao fonte e recompile o módulo. após isso a mensagem de “hello_world: module license ‘unspecified’ taints kernel.” irá sumir. Com essa declaração de licença GPL nosso módulo terá acesso aos símbolos do kernel GPL, isso é feito para garantir que tudo dentro do kernel seja GPL

Agora iremos remover nosso módulo das entranhas do kernel para isso outro utilitário rmmod


root@capsula:~/lkm# rmmod hello_world
root@capsula:~/lkm# dmesg
....
[ 105.300548] eth0: link up, 100Mbps, full-duplex
[ 115.782079] eth0: no IPv6 routers present
[16057.727314] Hello world 1.
[17080.476439] Goodbye world 1.
root@capsula:~/lkm#


Nossa este post estava ficando gigante, espero ter conseguido passar o assunto de forma objetiva. Qualquer dúvidas em relação ao assunto e claro se eu souber basta perguntar

Até a próxima.

Problema 1:
Se estiver tentando instalar um pacote e receber a mensagem

E: The package XXXX needs to be reinstalled, but I can’t find an archive for it.
E: Internal error opening cache (1). Please report.

ou

dpkg – warning, overriding problem because –force enabled:
Package is in a very bad inconsistent state – you should
reinstall it before attempting a removal.

ou

subprocess post-removal script returned error exit status 127
Errors were encountered while processing:

Solução: Utilize o comando “dpkg –remove –force-remove-reinstreq nome_do_pacote”, um exemplo para a remoção do pacote vim.

dpkg –remove –force-remove-reinstreq vim

Força a remoção do pacote inconsistente.

Problema 2

Se receber a seguinte mensagem:

The packages have files that are overwritten. – The packages have dependencies poorly resolved – There are conflicts between packages – a package can not be removed or updated by dpkg

Solução
execute os comandos

#echo “force-all” >/etc/dpkg/dpkg.cfg
#apt-get -f install

Problema 3

Um pacote é instalado e por alguma razão corrompido , você tenta instalar novamente e o apt-get diz que já esta instalado!

Solução:

#apt-get remove seu_pacote_corrompido
#apt-get update
#apt-get clean
#apt-get –reinstall install nome_do_pacote

Problema 4: O apt-get reclama que o repositório não tem a chave GPG(NO_PUBKEY) que serve para verificar a autenticidade dos pacotes

Solução:
Para resolver isso, execute o comando “apt-get update”

Copie o código que aparece no erro em negrito no log abaixo:

W: GPG error: ftp://ftp.debian.org/ testing Release:
The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 010908312D230C5F

W: There is no public key available for the following key IDs:
010908312D230C5F

Então rode os comandos com o key ID encontrado:

#gpg –keyserver pgpkeys.mit.edu –recv-key 010908312D230C5F
#gpg -a –export 010908312D230C5F | sudo apt-key add -

Problema 5: Mensagem de erro como

sub-processo post-installation script retornou estado de saída de erro -1
Erros foram encontrados durante o processamento de:

Solução
Para solucionar determine o nome do pacote que causou o erro, por exemplo no log abaixo, mostro em negrito o nome do pacote que causou o problema no meu caso(em negrito, xosview):

newaliases: warning: valid_hostname: numeric hostname: 69522
newaliases: fatal: bad parameter value: 69522
dpkg: error processing xosview (–configure):
subprocess post-installation script returned error exit status 75 sub-processo post-installation script retornou estado de saída de erro 75
Errors were encountered while processing:
Erros foram encontrados durante o processamento de:
xosview

Tendo determinado o nome do pacote, execute os comandos adaptado para teu pacote

#rm -f /var/lib/dpkg/info/xosview.post*
#rm -f /var/lib/dpkg/info/xosview.pre*
#apt-get -f install

Problema 6: Erro durante a remoção de pacote..

Solução

TROQUE abaixo a palavra pacote_defeituoso pelo nome do pacote que não quer ser removido e então rode estes comandos:

#rm -f /var/lib/dpkg/info/pacote_defeituoso.post*
#rm -f /var/lib/dpkg/info/pacote_defeituoso.pre*
#apt-get remove escreva_aqui_o_nome_do_pacote_defeituoso

Problema 7: Erro no /var/lib/dpkg/status…

Muitas vezes o apt-get da erros de leitura no arquivo /var/lib/dpkg/status

Solução

#cp /var/lib/dpkg/status-old /var/lib/dpkg/status

Problema 8: Se o problema de erro em /var/lib/dpkg/status… persiste ou exibe a mensagem “erro de out of room também” ou a mensagem abaixo

E: Dynamic MMap ran out of room

Solução

Edite o arquivo /etc/apt/apt.conf, aumentando o cache limit.

Apt::Cache-Limit “8388604″;

http://www.ubuntu-ac.org/archives/319
http://linuxhard.org/site/archives/1013

Espero que este post ajude. Afinal o apt tem o poder da vaca

root@Capsula:~# apt-get moo
       (__)
       (oo)
  /——\/
/  |    ||
* /\—/\
  ~~ ~~
….”Have you mooed today?”…
root@Capsula:~#

Att.

  Bom para começar a escrever meu plugin do nagios precisaria ver como funciona a parte de sockets no ruby ou usar uma biblioteca pronta. Para minha “sorte” essa bilblioteca existe

http://snmplib.rubyforge.org/

  Utilizei a snmplib, fiz alguns testes com sucesso fiquei impressionado com a rapidez de se “fazer as coisas”. O código que se segue funciona da seguinte forma, ele vai receber via parametros de linha de comando a comunidade SNMP, versão SNMP, nome do processo/aplicativo a verificar, um descritivo além do endereço IP.

#!/usr/bin/env ruby

include SNMP
require ‘optparse’
require ‘pp’
require ‘snmp’

optparse = OptionParser.new do|opts|
 opts.banner = “Usage: check_windows_processes_snmp.rb [options] host”

 options[:opt_comunidade] = nil
  opts.on( ‘-c’, ‘–comunidade NOME’, ‘Nomme da Comunidade SNMP’ ) do|comunidade|
  options[:opt_comunidade] = comunidade
end

 options[:opt_descricao] = nil
  opts.on( ‘-d’, ‘–descricao NOME’, ‘Descricao do processo’ ) do|descricao|
  options[:opt_descricao] = descricao
 end

 options[:opt_versao] = nil
  opts.on( ‘-v’, ‘–versao NOME’, ‘Versao SNMP’ ) d do|versao|
  options[:opt_versao] = versao
 end

 options[:opt_processo] = nil
  opts.on( ‘-p’, ‘–processo NOME’, ‘Nome do Processo’ ) do|processo|
  options[:opt_processo] = processo
 end

 opts.on( ‘-h’, ‘–help’, ‘Display this screen’ ) do
  puts opts
  exit
 end
end

optparse.parse!

if ( (options[:opt_versao] == nil) && (options[:opt_comunidade] == nil) && (options[:opt_processo] == nil) )
  puts “Argumentos inexistente: utilize o parametro -h para obter ajuda”
  exit
end

comunidade = options[:opt_comunidade]
processo = options[:opt_processo]
descricao = options[:opt_descricao]

case options[:opt_versao]
 when “1″
  versao = :SNMPv1
 when “2c”
  versao = :SNMPv2c
 when “3″
  versao = :SNMPv3
end

axou = 0

Manager.open(:Host => ARGV[0],:Version => versao, :Community => comunidade) do |manager|
 ifTable = ObjectId.new(“1.3.6.1.2.1.25.4.2.1.2″)
 next_oid = ifTable
 while next_oid.subtree_of?(ifTable)
  response = manager.get_next(next_oid)
  varbind = response.varbind_list.first
  next_oid = varbind.name
  string = varbind.to_s
  if string.match(processo)
   puts “Processo: #{descricao} STATUS: rodando”
   axou = 1
  end
 end
end

if ( axou != 1 )
 puts “Processo: #{descricao} STATUS: stop”
 exit
end

Encontrei um biblioteca muito interessante chamada optparse (http://ruby-doc.org/stdlib/libdoc/optparse/rdoc/classes/OptionParser.html) ela serve para manipular caracteres passados na linha de comando vamos dissecar esse código por partes. Abaixo declaração de bilblioteas como você faz em outras linguagens como C, Perl e python, etc.

include SNMP
require ‘optparse’
require ‘pp’
require ‘snmp’

Aqui declaramos um objeto do tipo “OptionParser” que será o obejto para manipular os parametros repassados pela linha de comandos. Um parametro interessante dessa biblioteca é o “objeto.on”, o qual insere cada parametros da linha de comando no caso criamos a opção de linha de comando “-c”, “-v”, “-p” e “-d” para você especificar a comunidade SNMP, versão do protocolo SNMP usado, nome do processo/aplicativo e descrição respectivamente.

optparse = OptionParser.new do|opts|
 opts.banner = “Usage: check_windows_processes_snmp.rb [options] host”

 options[:opt_comunidade] = nil
  opts.on( ‘-c’, ‘–comunidade NOME’, ‘Nomme da Comunidade SNMP’ ) do|comunidade|
  options[:opt_comunidade] = comunidade
 end

 options[:opt_descricao] = nil
  opts.on( ‘-d’, ‘–descricao NOME’, ‘Descricao do processo’ ) do|descricao|
  options[:opt_descricao] = descricao
 end

 options[:opt_versao] = nil
  opts.on( ‘-v’, ‘–versao NOME’, ‘Versao SNMP’ ) do|versao|
  options[:opt_versao] = versao
 end

 options[:opt_processo] = nil
  opts.on( ‘-p’, ‘–processo NOME’, ‘Nome do Processo’ ) do|processo|
  options[:opt_processo] = processo
 end

 opts.on( ‘-h’, ‘–help’, ‘Display this screen’ ) do
  puts opts
  exit
 end
end

Aqui fazemos uma validação(precaução) caso o usuário digite o script sem parametro algum.

if ( (options[:opt_versao] == nil) && (options[:opt_comunidade] == nil) && (options[:opt_processo] == nil) )
  puts “Argumentos inexistente: utilize o parametro -h para obter ajuda”
  exit
end

Definimos as variaveis comunidade, processo, descricao e versao obtidos atraves da biblioteca “optparse”. Uma pecualiaridade manipulamos a variavel versao para utilizar a MACRO correspondente a versão do protocolo SNMP. Utilizei uma variavel “axou” para manipular quando encontrar o retorno da busca.

comunidade = options[:opt_comunidade]
processo = options[:opt_processo]
descricao = options[:opt_descricao]

case options[:opt_versao]
  when “1″
    versao = :SNMPv1
  when “2c”
    versao = :SNMPv2c
  when “3″
    versao = :SNMPv3
end

axou = 0

Abaixo temos a parte do código que faz o “get” na MIB dos servidores via biblioteca “snmplib”, são passados os parametros host, versão, comunidade, e o retorno e analisado com o nome do processo passado via linha de comando se der “match” ele escreve que o processo esta rodando no servidor em questão, senão(a variavel “axou” esta definida como falso ou seja igual a zero), ele testa a variavel axou e printa que o processo não esta sendo executado.

Manager.open(:Host => ARGV[0],:Version => versao, :Community => comunidade) do |manager|
   ifTable = ObjectId.new(“1.3.6.1.2.1.25.4.2.1.2″)
   next_oid = ifTable
   while next_oid.subtree_of?(ifTable)
     response = manager.get_next(next_oid)
     varbind = response.varbind_list.first
     next_oid = varbind.name
    string = varbind.to_s
    if string.match(processo)
      puts “Processo: #{descricao} STATUS: rodando”
      axou = 1
    end
   end
end

if ( axou != 1 )
  puts “Processo: #{descricao} STATUS: stop”
  exit
end

Abaixo segue a execução do script.

ricardobarbosa@capsula:~$ ./check_snmp.rb
Argumentos inexistente: utilize o parametro -h para obter ajuda
ricardobarbosa@capsula:~$ ./check_snmp.rb -h
Usage: check_windows_processes_snmp.rb [options] host
-c, –comunidade NOME Nomme da Comunidade SNMP
-d, –descricao NOME Descricao do processo
-v, –versao NOME Versao SNMP
-p, –processo NOME Nome do Processo
-h, –help Display this screen
ricardobarbosa@capsula:~$

Testamos o snmp via comando snmpwalk do tools net-snmp(http://www.net-snmp.org/), vamos buscar os nomes de todos os processos.

ricardobarbosa@capsula:~$ snmpwalk -c public -v 2c 192.168.1.3 hrSWRunName
HOST-RESOURCES-MIB::hrSWRunName.1 = STRING: “init”
HOST-RESOURCES-MIB::hrSWRunName.2 = STRING: “kthreadd”
HOST-RESOURCES-MIB::hrSWRunName.3 = STRING: “migration/0″
HOST-RESOURCES-MIB::hrSWRunName.4 = STRING: “ksoftirqd/0″
HOST-RESOURCES-MIB::hrSWRunName.5 = STRING: “watchdog/0″
HOST-RESOURCES-MIB::hrSWRunName.6 = STRING: “events/0″
HOST-RESOURCES-MIB::hrSWRunName.7 = STRING: “khelper”
HOST-RESOURCES-MIB::hrSWRunName.41 = STRING: “kblockd/0″
HOST-RESOURCES-MIB::hrSWRunName.44 = STRING: “kacpid”
HOST-RESOURCES-MIB::hrSWRunName.45 = STRING: “kacpi_notify”
HOST-RESOURCES-MIB::hrSWRunName.88 = STRING: “kseriod”
HOST-RESOURCES-MIB::hrSWRunName.123 = STRING: “pdflush”
HOST-RESOURCES-MIB::hrSWRunName.124 = STRING: “pdflush”
HOST-RESOURCES-MIB::hrSWRunName.125 = STRING: “kswapd0″
HOST-RESOURCES-MIB::hrSWRunName.167 = STRING: “aio/0″
HOST-RESOURCES-MIB::hrSWRunName.1289 = STRING: “ata/0″
HOST-RESOURCES-MIB::hrSWRunName.1294 = STRING: “ata_aux”
HOST-RESOURCES-MIB::hrSWRunName.1308 = STRING: “scsi_eh_0″
HOST-RESOURCES-MIB::hrSWRunName.1312 = STRING: “scsi_eh_1″
HOST-RESOURCES-MIB::hrSWRunName.2317 = STRING: “kjournald”
HOST-RESOURCES-MIB::hrSWRunName.2473 = STRING: “udevd”
HOST-RESOURCES-MIB::hrSWRunName.2667 = STRING: “kpsmoused”
HOST-RESOURCES-MIB::hrSWRunName.3648 = STRING: “dhclient3″
HOST-RESOURCES-MIB::hrSWRunName.4041 = STRING: “getty”
HOST-RESOURCES-MIB::hrSWRunName.4044 = STRING: “getty”
HOST-RESOURCES-MIB::hrSWRunName.4047 = STRING: “getty”
HOST-RESOURCES-MIB::hrSWRunName.4051 = STRING: “getty”
HOST-RESOURCES-MIB::hrSWRunName.4053 = STRING: “getty”
HOST-RESOURCES-MIB::hrSWRunName.4090 = STRING: “syslogd”
HOST-RESOURCES-MIB::hrSWRunName.4109 = STRING: “dd”
HOST-RESOURCES-MIB::hrSWRunName.4111 = STRING: “klogd”
HOST-RESOURCES-MIB::hrSWRunName.4130 = STRING: “sshd”
HOST-RESOURCES-MIB::hrSWRunName.4186 = STRING: “mysqld_safe”
HOST-RESOURCES-MIB::hrSWRunName.4228 = STRING: “mysqld”
HOST-RESOURCES-MIB::hrSWRunName.4229 = STRING: “logger”
HOST-RESOURCES-MIB::hrSWRunName.4313 = STRING: “asterisk”
HOST-RESOURCES-MIB::hrSWRunName.4359 = STRING: “atd”
HOST-RESOURCES-MIB::hrSWRunName.4370 = STRING: “cron”
HOST-RESOURCES-MIB::hrSWRunName.4392 = STRING: “apache2″
HOST-RESOURCES-MIB::hrSWRunName.4408 = STRING: “apache2″
HOST-RESOURCES-MIB::hrSWRunName.4410 = STRING: “apache2″
HOST-RESOURCES-MIB::hrSWRunName.4412 = STRING: “apache2″
HOST-RESOURCES-MIB::hrSWRunName.4413 = STRING: “apache2″
HOST-RESOURCES-MIB::hrSWRunName.4414 = STRING: “apache2″
HOST-RESOURCES-MIB::hrSWRunName.4415 = STRING: “miniserv.pl”
HOST-RESOURCES-MIB::hrSWRunName.4422 = STRING: “login”
HOST-RESOURCES-MIB::hrSWRunName.4423 = STRING: “bash”
HOST-RESOURCES-MIB::hrSWRunName.4439 = STRING: “bash”
HOST-RESOURCES-MIB::hrSWRunName.4855 = STRING: “snmpd”
ricardobarbosa@capsula:~$

Em seguida executamos nosso script em busca do processo apache2 e do postfix para verificar a inexistencia do processo.

ricardobarbosa@capsula:~$ ./check_snmp.rb -c public -v 2c -d “Servidor HTTP APACHE2″ -p apache2 192.168.1.3
Processo: Servidor HTTP APACHE2 STATUS: rodando
ricardobarbosa@capsula:~$
ricardobarbosa@capsula:~$ ./check_snmp.rb -c public -v 2c -d “Servidor SMTP POSTFIX” -p master 192.168.1.3
Processo: Servidor SMTP POSTFIX STATUS: stop
ricardobarbosa@capsula:~$

Agora e necessário configurar o arquivo checkcommands.cfg do nagios e inserir o comando com as variaveis.(para o post não ficar muito extenso não vou passar essa configuração num post futuro eu farei isso )
Não sou desenvolvedor atualmente mas já trabalhei como desenvolvedor delphi e php. Gosto de criar códigos que me ajudem na infra-estrutura. Espero que o post seja útil até a próxima.

Att.