terça-feira, 31 de março de 2009

Nmap 4.85BETA5 lançado para escanear Conficker

O malware Conficker tem recebido muita atenção da mídia pois tem trabalhado em vasta escala e ja infectou milhoes de maquinas.

Com isso o pessoal do Insecure.org juntamente com a galera do The Honeynet Project
lançou uma nova versão beta do famoso portscan Nmap, o Nmap 4.85BETA5 pode ser baixado
no link a seguir:
http://nmap.org/download.html

Para escanear uma maquina pera ver se ela esta infectada com o Conficker basta executar o comando a seguir:
nmap -PN -T4 -p139,445 -n -v --script=smb-check-vulns --script-args safe=1 [Rede de destino]

Fonte:
http://insecure.org/


By CleBeer

quarta-feira, 25 de março de 2009

Quebrando captcha por dinheiro

É incrível até onde vai a criatividade humana a favor do mal...rsrsrs
com certeza você já deve ter se deparado com um CAPTCHA em sua vida, captcha é aquela figura com vários caracteres que é utilizado em sistemas como tira-teima do email UOL, quando você erra a senha do gmail e no easy-share quando vai baixar um arquivo. A figura a segui é um exemplo de captcha:


A sigla captcha significa "Completely Automated Public Turing test to tell Computers and Humans Apart" Que traduzindo para o português seria algo como "teste de turing público completamente automatizado para diferenciar entre computadores e humanos."
Este tipo de proteção é utilizado para evitar que propgramas acessem informações (como cadastro de usuários, envio de email ou perquisas) se passando por um ser humano, se bem que certa vez eu vi um captcha que a meu ver era humanamente impossível de resolver...rrs
Pois é mas hoje eu vi um site que fornece o serviço de quebrar captchas, pois é com a módica quantia de dois dolares (pouco menos de cinco reais) você compra um pacote para quebrar mil captchas, legal que o site tem F.A.Q e garantia, "You pay for correctly recognized CAPTCHAs only" (você só paga pelo captcha que forem reconhecidos corretamente...rsrs)

Interessado no serviço?
veja o site:
http://decaptcher.com/client/

Legal do site deles é que eles também utilizam Captcha..rsrsrs


By CleBeer.

Super rootkit resiste a formatação do HD

Pesquisadores tem demonstrado como criar rootkits que permanecem na máquina mesmo após formatação do HD colocando o código malicioso na BIOS do computador.

Mais em:
http://www.theregister.co.uk/2009/03/24/persistent_bios_rootkits/

By CleBeer...

terça-feira, 24 de março de 2009

Mojito

Hehe nem só de bits vive um geek...
um dos drinks que mais curto é o Mojito por isso vou postar a receita dele aqui:

Ingredientes

2 ramos de hortelã
1 colher (sopa) de açúcar
Gelo em cubos
3 colheres (sopa) de rum branco
Suco de 1/2 limão
Club soda ou água com gás

Preparo

Coloque 3 a 4 folhas de hortelã num copo alto, adicione o açúcar e amasse bem.
Acrescente alguns cubos de gelo, o rum, o suco de limão e complete com club soda ou água com gás.
Mexa rapidamente e sirva decorado com a hortelã restante.

By CleBeer |_b

Kernel Linux versão 2.6.29

Ontem saiu a nova versão do kernel linux 2.6.29
com o codinome "Temporary Tasmanian Devil." Dentre as
principais mudanças estão o suporte ao sistema de arquivo "Btrfs"
que foi inicialmente desenvolvido pela Oracle (Este ainda esta em teste e não é aconselhavel
o uso a não ser que você va testar o sistema de arquivos), suporte ao sistema de arquivos
squashfs e um modo de configuração específico para placas de vídeo Intel.

Maiores detalhes em:
http://kernelnewbies.org/Linux_2_6_29

DNS (Cultura Inútil)

Se um dia você estiver com problemas no seu sistema de DNS o único site que você provavelmente conseguirá acessar é o da "Southern Air Inc", porquê? porque você vai lembrar do endereço. "http://12.34.56.7"

sexta-feira, 20 de março de 2009

Websense classifica erroneamente cisco.com como site hacker

No inicio desta semana o websense classificou erroneamente o site da Cisco como site Hacker, por cerca de 15 minutos os usuários do websense ficaram impossibilitados de acessar o site da Cisco. Segundo a Websense isso ocorreu porque o endereço IP utilizado pelo host www.cisco.com estava associado anteriormente a um site hacker.

Fonte:
The Register

Como trabalha o Kernel Linux

Ao procurar a definição da palavra "Kernel" em um dicionário (inglês/inglês) percebi que ele deu ênfase ao seguinte ponto: “The most important part of a statement, idea, plan, etc” e também “a very small part or amount of something”. A partir daqui já temos uma idéia de que é algo muito importante, pois mesmo sendo muito pequeno o kernel é o cara que gerencia a interface de comunicação entre o hardware o os programas instalados no computador. Quando falamos do Linux estamos falando exclusivamente deste kernel, todo o resto como gnome, firefox e até mesmo o bash tratam-se apenas de programas que rodam no Linux e não fazem parte do Sistema Operacional (kernel linux).

Entendendo o kernel

OK, mas oque exatamente faz esse tal de kernel? A figura a seguir mostra de uma forma geral como o kernel disponibiliza serviço para os aplicativos rodando através de inúmeros pontos de entrada conhecidas como chamadas de sistema (system calls).



O kernel utiliza chamadas de sistema como leitura e escrita pra prover acesso ao hardware.

Do ponto de vista de um programador isso parece uma função comun, embora na realidade uma chamada de sistema envolva diferentes interruptores no modo de operação do "kernel space" para o "user space" Juntos esse conjunto de chamadas de sistema formam uma especie de "maquina virtual" que trabalha antes do hardware real. Um exemplo claro disso é o sistema de arquivos.


Kernel Modular

Agora que entendemos melhor o que o kernel faz, vamos olhar mais atentamente a sua organização física. As primeiras versões do kernel eram monolíticas, ou seja, todos os módulos estavam compilados dentro de um único arquivo executavel. O kernel das distribuições mais novas são modulares, ou seja, os módulos podem ser carregados no kernel em tempo de execução, isso faz com que o núcleo do kernel fique menor e não seja necessário reiniciar a maquina para carregar ou substituir novos módulos.
O núcleo do kernel é carregado na memória na hora do boot e é lido de um arquivo no diretório “/boot” na maioria das vezes este arquivo é chamado de “vmlinuz-VERSÃO_DO_KERNEL”. Para ver a versão do kernel corrente utilize o comando:

---
#uname -r
---

Os módulos ficam no diretório “/lib/modules/VERSÃO_DO_KERNEL/”


Gerenciando módulos.

Veremos agora alguns comandos para gerenciar os módulos do seu kernel, como por exemplo o comando para listar os módulos carregados que é o “lsmod”, o lsmod vai te mostrar uma saída semelhante a esta:

---
Module Size Used by
vfat 14464 0
isofs 36388 0
fat 54556 1 vfat
nfs 262540 0
lockd 67720 1 nfs
nfs_acl 4608 1 nfs
sunrpc 185500 5 nfs,lockd,nfs_acl
bridge 55576 0
tun 12672 0
usb_storage 73792 4
libusual 19236 1 usb_storage
---

Esta saída possui quatro campos divididos por nome do módulo que esta carregado, o tamanho do módulo, quantas vezes ele esta sendo utilizado e quais os módulos que dependem dele. Podemos carregar um módulo utilizando o comando “modprobe” (podemos também utilizar o comando “insmod” porém o modprobe é mais aconselhavel pois ele resolver as dependencias do módulo). Outro ponto muito importante na saída do comando lsmod é o terceiro campo que indica a quantidade de vezes que o módulo esta sendo utilizado pois o linux não vai permitir a remoção de um módulo cujo o campo used seja diferente de zero, no exemplo acima vemos o módulo “isofs” (utilizado para dar suporte ao sistema de arquivos “ISO” que é utilizado em Cds) com o campo used “0” neste caso podemos remover o módulo com o comando “modprobe -r isofs”, após executar este comando o módulo isofs não vai aparecer mais quando executarmos o lsmod.
Não é muito comum carregar módulos manualmente no dia a dia, porém se você precisar carregar um módulo manualmente você pode incluir parâmetros específicos de cada módulo para carrega-lo, como no exemplo a seguir:
---
modprobe usb_storage delay_use:3
---

No exemplo supra-citado habilitamos o parâmetro “delay_use:3” para o módulo “usb_storage” que define um time-out de 3 segundos para o módulo procurar um novo device. Para saber quais as opções de cada módulo utilizamos o comando modinfo como no exemplo a seguir:

---
# modinfo usb_storage
filename: /lib/modules/2.6.24-23-generic/kernel/drivers/usb/storage/usb-storage.ko
license: GPL
description: USB Mass Storage driver for Linux
author: Matthew Dharm
srcversion: 99E0EB653929DE200DF6AF9
depends: libusual,usbcore,scsi_mod
vermagic: 2.6.24-23-generic SMP mod_unload 586
parm: delay_use:seconds to delay before using a new device (uint)
---

A linha que nos interessa neste caso é a que começa com “param” que mostra os parâmetros aceitos pelo módulo. Caso você possua a source do kernel você também pode encontrar uma documentação muito útil em “/usr/src/VERSÂO_DO_KERNEL/Documentation/kernel-parameters.txt”

Sistema de arquivos /proc

O kernel também nos fornece inúmeras informações que podem ser encontradas no sistema de arquivos “/proc”, os arquivos no /proc são criados pelo kernel (alguns você pode alterar, outros não) um exemplo claro do tipo de informação que podemos encontrar no /proc esta to arquivo “/proc/modules” que mostra todos os módulos carregados no sistema (sim é semelhante ao comando lsmod.. =D), no arquivo “/proc/meminfo” que mostra o status detalhado da memória do sistema e também o arquivo “/proc/net/arp” que mostra a tabela ARP (mesma tabela exibida pelo comando “arp -a”).
Beleza falei do /proc mas só citei arquivos que não podem ser alterados, são arquivos que somente nos fornecem algumas informações, mas o /proc não é só isso, um subdiretório do /proc muito importante é o “sys”, por exemplo o arquivo “/proc/sys/net/ipv4/ip_forward” define que o kernel irá encaminhar pacotes IP, a sintaxe é muito simples se o conteúdo deste arquivo for “0” (zero) o kernel não fará encaminhamento de pacotes IP e se o conteúdo for “1” (Um) o kernel fará encaminhamento de pacotes IP, esta opção deve ser habilitada se você for utilizar o linux como um roteador; ta com mas como eu habilito isso?
Vamos primeiro ver como esta o arquivo:

---
# cat /proc/sys/net/ipv4/ip_forward
0
---

Vemos que o conteúdo do arquivo é “0” (zero), agora vamos habilitar o encaminhamento de pacotes IP no kernel.
---
# echo 1 > proc/sys/net/ipv4/ip_forward
---
Pronto agora o encaminhamento de pacotes IP esta habilitado, fácil né? Outro comando que também pode ser utilizado para executar a mesma tarefa é o “sysctl” como no exemplo a seguir:

---
#sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
---

No exemplo acima utilizamos o comando sysctl para ver o valor do ip_forward, para alterar este valor utilizamos o comando sysctl com as seguintes opções:

---
#sysctl -w net.ipv4.ip_forward = 1
---

Porém tem um pequeno problema aqui, se reiniciarmos a maquina este arquivo voltara a ter conteúdo igual a “0” (zero). E como solucionamos isso? A solução e muito fácil utilizamos o arquivo “/etc/sysctl.conf” para definir os valores que serão configurados na hora do boot, então basta acrescentarmos a linha “net.ipv4.ip_forward = 1” no arquivo sysctl.conf.

Melhorando a performance.

Muitos dos parâmetros do /proc/sys que permitem escrita podem ser utilizados para melhorar a performance do Linux, apesar de que a configuração padrão já habilite opções que trabalham muito bem. Um exemplo de como podemos modificar o kernel para melhorar a performance de acordo com o tipo de aplicação que você vai utilizar esta no guia de instalação do Oracle 10g (http://www.oracle.com/technology/obe/obe10gdb/install/linuxpreinst/linuxpreinst.htm) que pede pra você configurar alguns parâmetros como o “kernel.shmmax=2147483648” que define o tamanho máximo de segmento de memória partilhada para 2GB. (Memória partilhada é um mecanismo de comunicação entre processos que permite que um segmento de memória de ser visível dentro do espaço de endereçamento de múltiplos processos.)
Outra modificação que podemos fazer e definir que nossa máquina não vai responder por broadcast de icmp (o bom e velho ping -b 255.255.255.255) configurando o sysctl da seguinte forma:

---
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
---

Agora fica a seguinte dúvida, pra ver os valores eu vou ter que dar cat de arquivo em arquivo ou saber todos os caminhos do comando sysctl? Claro que não, basta utilizar o comando

---
sysctl -a
---

..que ele vai exibir todos os parâmetros e seu valores porém ele não fala pra que serve cada um deles porém isso podemos encontrar os detalhes no bom e velho “man proc” Ta vendo, o kernel não é aquele bicho de sete cabeças que muitos imaginam....rsrsr

By CleBeer....
[email protected]
clebeerpub.blogspot.com

Representação geográfica de alertas do snort

Um dos engenheiros da Source Fire desenvolveu um perl script que pega os alertas gerados pelo snort ou apliances Source Fire e mapea o evento utilizando o google earth.

Maiores detalhes no site do autor do script: aqui
O script pode ser baixado aqui

SSH - Muito mais que um simples shell seguro

Para quem administra vários servidores, hoje em dia o ssh faz-se mais do que necessário para agilizar a execução de comandos remotos. Entretanto, já presenciei diversas cenas em que determinado usuário não sabe o poder que o ssh nos oferece e acaba utilizando-o apenas como uma simples ferramenta para login remoto, deixando de lado outras poderosas funcionalidades.

O intuito deste tutorial é mostar algumas funcionalidades do ssh, que ajudam e muito no dia-a-dia do administrador.

1. Troca de Chaves

Certa vez um aluno me contou que queria criar um script de backup remoto utilizando o ssh (scp), porém não estava conseguindo fazer o script ler um arquivo com a senha (gravada em texto-plano) e inserí-la na hora em que o ssh pede a senha do usuário. Então perguntei para ele:

- Por que você quer utilizar o SSH ao invés de FTP?
- Porque é mais seguro.
- O que tem de seguro em colocar a senha em texto-plano dentro de um arquivo?
- …

Ele não soube o que responder. Falei pra ele utilizar a troca de chaves. Com esse método, as máquinas possuem uma chave pública e uma chave privada que podem ser geradas com o comando ssh-keygen. Neste tutorial estaremos utilizando um usuario chamado “usuario” para executar todo o procedimento, mas isso não impede de você utilizar qualquer usuário ou até o root. Mas nesse caso, lembre-se sempre de substituir os diretórios HOME quando houver referência e o próprio nome de usuário.

Primeiro gere as chaves da seguinte forma:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/usuario/.ssh/id_rsa): # Aqui ele pergunta onde você quer gerar a chave
Enter passphrase (empty for no passphrase): # Aqui ele pergunta se quer senha na chave (deixe em branco)
Enter same passphrase again: # Aqui ele confirmação da senha (deixe em brando novamente)
Your identification has been saved in /home/usuario/.ssh/id_rsa.
Your public key has been saved in /home/usuario/.ssh/id_rsa.pub.
The key fingerprint is:
b3:12:2e:9b:b7:9b:56:f2:ba:fa:d7:71:74:74:99:b2 usuario@desktop-brandao

No final, dá para ver que ele mostra onde gravou as chaves pública e privada.

Este comando deve ser executado na maquina cliente, neste caso a máquina que vai enviar os arquivos. Verificando o arquivo ~/.ssh/id_rsa.pub (no cliente), teremos algo parecido com o exibido abaixo:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwN3WxdXANQxGW+gev3yrQKFzdpyuypmJGRQh6k
khB+axeCf/oQQTopHQPSJDpMtrWAXK8ZrYSlOgtLZQjjk0U1UDzYJ1Qcpq9Fh9b8NQBZLYuYimbFHuo
HZ1VGgmVkoaAQ31bKuaIK9Z2LvnR+YKPH6hPaDS9lCyW0xRAT4xSvK8S7ZrozEZUjQZ4+IMNN/yu5+
zalIzZyqXlRcDk+lV8PfR9p0EXQTaKRrNJz+sD6Yld5Ty7igd6bsGNa/pK6rxY0FLnPX/u4xjmDU1m
VNgFJ8zNcb6ibzv4IUk9xhVRDJKgW4xSNN7LEe2asjVXJ87UU/hkUGTLNGwg5c4hFWZ1w== usuario@desktop-brandao

(Esta é apenas uma linha, quebramos em várias linhas para melhor visualização neste tutorial).

Esta é a chave pública que deve ser adicionada no servidor, no arquivo definido na tag “AuthorizedKeysFile” na configuração /etc/ssh/sshd_config do servidor. Por padrão, este arquivo é o “authorized_keys” dentro do diretório .ssh (notem o ponto) no HOME de cada usuário. Neste exemplo vamos definir a tag AuthorizedKeysFile para utilizar o arquivo /etc/ChavesSSH. Utilizando um editor de texto de sua preferência, acesse o arquivo /etc/ssh/sshd_config e deixe a linha do AuthorizedKeysFile como a seguir:

AuthorizedKeysFile    /etc/ChavesSSH

Reinicie o ssh para que as novas configurações sejam aplicadas:

/etc/init.d/sshd restart

Após isso, no servidor, crie o arquivo /etc/ChavesSSH e adicione a chave tirada do arquivo ~/.ssh/id_rsa.pub que está no cliente. Você pode copiar e colar ou transferir o arquivo via scp e concatená-lo (recomendado). No caso de transferir e concatenar, faça algo parecido com isto:

maquina-cliente$ scp ~/.ssh/id_rsa.pub [email protected]:/home/usuario
Enter password:
[...]

maquina-servidor# cat /home/usuario/id_rsa.pub >> /etc/ChavesSSH

(Lembrando de substituir o 192.168.0.254 pelo IP remoto do servidor).

Ao fazer isto, a chave do cliente estará dentro do arquivo de chaves autorizadas à fazer logins na conta, ou seja, se você tiver a chave privada (~/.ssh/id_rsa) correspondente, poderá se logar com qualquer usuário no sistema remoto. Na máquina cliente, execute o comando:

$ ssh  -l root

Pronto, você verá que se logou na máquina servidor sem precisar digitar senha :)

Você também pode incrementar esta configuração. Por exemplo, se você quiser que esta chave só seja aceita se partir de uma determinada origem de IP (Ex.: 192.168.0.1), você pode adicionar no arquivo /etc/ChavesSSH a opção “from”, como mostrado na linha a seguir:

from="192.168.0.1" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwN3WxdXANQxGW+gev3yrQKFzdpyuypmJGRQh6k
khB+axeCf/oQQTopHQPSJDpMtrWAXK8ZrYSlOgtLZQjjk0U1UDzYJ1Qcpq9Fh9b8NQBZLYuYimbFHuo
HZ1VGgmVkoaAQ31bKuaIK9Z2LvnR+YKPH6hPaDS9lCyW0xRAT4xSvK8S7ZrozEZUjQZ4+IMNN/yu5+
zalIzZyqXlRcDk+lV8PfR9p0EXQTaKRrNJz+sD6Yld5Ty7igd6bsGNa/pK6rxY0FLnPX/u4xjmDU1m
VNgFJ8zNcb6ibzv4IUk9xhVRDJKgW4xSNN7LEe2asjVXJ87UU/hkUGTLNGwg5c4hFWZ1w== usuario@desktop-brandao

(Mais uma vez, lembre-se que esta é apenas uma linha

Repare que apenas foi adicionada a opção from=”192.168.0.1″ no inicio da linha.

Outra opção legal é limitar a utilização do usuário apenas à comandos, evitando assim que o usuário ganhe uma shell na máquina. Deste modo, o usuário poderá apenas executar comandos remotos ou utilizar o scp para transferência de arquivos. A configuração é simples, basta adicionar a opção no-pty no início da linha no /etc/ChavesSSH, deixando-a como a seguir:

no-pty,from="192.168.0.1" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwN3WxdXANQxGW+gev3yrQKFzdpyuypmJGRQh6k
khB+axeCf/oQQTopHQPSJDpMtrWAXK8ZrYSlOgtLZQjjk0U1UDzYJ1Qcpq9Fh9b8NQBZLYuYimbFHuo
HZ1VGgmVkoaAQ31bKuaIK9Z2LvnR+YKPH6hPaDS9lCyW0xRAT4xSvK8S7ZrozEZUjQZ4+IMNN/yu5+
zalIzZyqXlRcDk+lV8PfR9p0EXQTaKRrNJz+sD6Yld5Ty7igd6bsGNa/pK6rxY0FLnPX/u4xjmDU1m
VNgFJ8zNcb6ibzv4IUk9xhVRDJKgW4xSNN7LEe2asjVXJ87UU/hkUGTLNGwg5c4hFWZ1w== usuario@desktop-brandao

(Mais uma vez, lembre-se que esta é apenas uma linha

Note que também foi adicionada uma vírgula entre a tag no-pty e a tag from, ou seja, você pode combinar várias opções separando-as com vírgula.

Outras opções legais para se adicionar no arquivo de chaves podem ser obtidas na sessão 8 do man do sshd:

$ man 8 sshd

2. Configurações avançadas

O arquivo sshd_config oferece diversas opções que podem nos ajudar no dia-a-dia. Coloquei aqui as opções que mais me chamam atenção.

2.1. Port

Utilidade: A opção port serve para definir em qual porta o daemon do ssh (sshd) aceita novas conexões.

Comentário: Apesar de muitas pessoas acreditarem que trocando a TAG Port para uma outra porta estarão assegurando que o ssh ficara seguro, isso apenas causa uma falsa impressão de segurança, pois utilizando um simples port-scanning com o nmap ou programas similares, podemos verificar em que porta o daemon está escutando e qual a versão do serviço, utilizando a opção -sV

Exemplo:

# nmap localhost -sV
222/tcp open ssh OpenSSH 4.7 (protocol 2.0)

Veja que mesmo estando na porta 222, o nmap conseguiu ver que o serviço rodando na porta é o ssh.

2.2. ListenAddress

Utilidade: Esta opção é útil para definir um endereço IP específico em que o daemon ficará escutando no servidor, caso o servidor possua mais de uma interface de rede (física ou virtual).

Comentário: Esta opção é legal para servidores que ficam ligados diretamente a Internet, pois você pode definir que o daemon do ssh aceitará somente conexões oriundas da sua rede local.

Exemplo:

ListenAddress    192.168.0.254

2.3. LogLevel

Utilidade: Esta opção nos oferece diversos níveis de log para analisarmos.

Comentário: Os níveis disponíveis nesta opção são as seguintes: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, e DEBUG3. A opção que vem habilitada por padrão é a INFO, porém a que mais me chama a atenção é a DEBUG, que fornece todas as informações de possamos desejar.

2.4. PermitRootLogin

Utilidade: Esta opção serve para permitir ou não que o usuário root possa se logar via ssh.

Comentário: Esta opção é legal para evitar ataques de força bruta, pois o usuário root existe em qualquer sistema Linux/Unix e a maioria das tentativas de invasão tentam se logar como root.

2.5. AllowGroups

Utilidade: Esta opção nos permite estabelecer um grupo de usuários que poderão efetuar login via ssh.

Comentário: Esta opção é muito legal para definir, por exemplo, um grupo de administração do servidor e permitir o login via ssh somente dos usuários pertencentes à um certo grupo.

Exemplo:

AllowGroups    admin

2.6. AuthorizedKeysFile

Utilidade: Como visto no primeiro tópico deste tutorial, esta opção é utilizada para definir o arquivo com as chaves públicas dos usuários que poderão efetuar login sem precisar digitar a senha.

Comentário: Esta opção é muito útil para pessoas que administram muitos servidores com senhas diferentes, ao invés de ter que decorar todas as senhas ele pode exportar a sua chave pública e efetuar o login via troca de chaves. Por padrão este arquivo vem definido como ~/.ssh/authorized_keys, porém você pode definir qualquer arquivo como arquivo de chaves, como vimos no primeiro tópico deste tutorial.

Termino por aqui e espero que este tutorial seja útil.

quinta-feira, 19 de março de 2009

Como perder uma ótima oportunidade de emprego.

O twitter virou febre entre os geeks de plantão, eu mesmo as vezes atualizo ele até qdo estou no banheiro, mas como muitas coisas na net podem ser utilizadas tanto para o bem quanto para o mal, um cara muito "esperto" recebeu uma proposta de emprego da Cisco e postou no twitter uma mensagem :
--
"A Cisco me ofereceu um emprego, e agora eu preciso pesar a utilidade de um gordo salário contra viajar todo dia pra San Jose e detestar o trabalho"
--
Logo ele recebeu uma resposta bem legal de um advogado da Cisco.

--
“Quem é o gerente de contração(?). Tenho certeza que eles adorariam saber que você vai odiar o trabalho."
--

Hehe Desgraça pouca é bobagem

Detalhes em:
http://ciscofatty.com/ruin-a-fatty-cisco-job-with-1-tweet/

By CleBeer |_b