Powered By Blogger

domingo, 13 de março de 2011

terça-feira, 1 de fevereiro de 2011

configurando rede entre 2 micros!

Configurar redes já foi complicado. Hoje em dia, o grande desafio não é configurar uma rede, mas fazer isso rápido, a fim de transferir alguns arquivos, jogar uma partida de Warcraft 3, compartilhar temporariamente a conexão do seu amigo com o seu notebook e assim por diante.

As duas formas mais rápidas e baratas de criar uma rede entre dois micros são:

a) Usar um cabo cross-over

b) Configurar uma rede wireless ad-hoc (no caso de dois notebooks com placas wireless)

Os cabos de rede "normais", são chamados de cabos retos, ou "straight". Eles são chamados de retos simplesmente por que usam o mesmo padrão nos dois lados do cabo. Ou seja, o fio crimpado no primeiro pino do lado A, vai ser crimpado também no primeiro pino do lado B, e assim por diante. Os dois lados do cabo são iguais.

Os cabos cruzados, ou cross-over possuem a posição de dois dos pares trocadas numa das pontas. Essa combinação permite que dois micros conversem diretamente, sem precisar de um hub. Você simplesmente liga o cabo e tem uma rede instantânea entre os dois.

cross

Você pode comprar cabos em qualquer loja de informática que se preze, mas se você é da época em que homem eram homens e crimpavam seus próprios cabos, a pinagem de um cabo cross é a seguinte:

Lado A:

1- Branco com Laranja
2- Laranja
3- Branco com Verde
4- Azul
5- Branco com Azul
6- Verde
7- Branco com Marrom
8- Marrom

Lado B:

1- Branco com Verde
2- Verde
3- Branco com Laranja
4- Azul
5- Branco com Azul
6- Laranja
7- Branco com Marrom
8- Marrom

Os cabos são encaixados nesta ordem, com a trava do conector virada para baixo, como no diagrama:

cabo


Com os dois micros ligados, falta apenas configurar o IP em ambos para que eles comecem a conversar.

No Windows XP, você configura a rede no Painel de Controle > Conexões de Rede. Clique com o botão direito sobre o "Conexão local" e acesse as propriedades do Protocolo TCP/IP.

Configure os dois micros usando endereços IP diferentes, como "192.168.0.1" e "192.168.0.2", por exemplo e use a máscara "255.255.255.0" em ambos. O Gateway e o DNS são necessários apenas para acessar a Internet, não para fazer uma rede simples entre dois micros.

win1

Para compartilhar arquivos entre as duas máquinas, não se esqueça de manter o "Cliente para redes Microsoft" e o "Compartilhamento de arquivos e impressoras para redes Microsoft" ativados na configuração da rede. Você precisa também colocar as duas máquinas no mesmo grupo de trabalho, que você define no Meu Computador > Propriedades > Nome do Computador.

win2

No Linux é mais simples, pois você pode configurar o IP e ativar a rede, independentemente da distribuição usada, com um único comando, como em:

# ifconfig eth0 192.168.0.1 up(como root)
A menos que você tenha mais de uma placa de rede, sua placa cabeada será sempre a eth0. O "192.168.0.1" é o IP que está sendo atribuído e o "up" conclui o comando, dizendo que a placa deve ser ativada imediatamente.

Agora você só precisa ativar o segundo micro, configurando-o com um IP diferente, como em:

# ifconfig eth0 192.168.0.2 up
Lembre-se que tanto no Linux, quanto no Windows, você pode usar o comando "ping" para testar a conectividade entre os dois micros (ele não funciona se você estiver usando firewall). Abra o terminal (ou o prompt do DOS, no caso do Windows) e consulte o outro micro, como em:

ping 192.168.0.1
Uma forma rápida e fácil de transferir arquivos entre duas máquinas Linux é ativar o servidor SSH na máquina que fará papel de servidor e usar o "fish://" do Konqueror na máquina que ficará como cliente. Abra uma janela do Konqueror na segunda máquina e, na barra de endereços, digite:

fish://usuario@192.168.0.1

Aqui, o "usuário" e um login da outra máquina e o "192.168.0.1" é o IP. Ele vai pedir a senha da conta. A partir daí o gerenciador passa a mostrar os arquivos da outra máquina e você pode transferir simplesmente arrastando.

fish

O SSH permite várias outras coisas além de transferir arquivos. Você pode ler mais sobre ele no meu Guia de acesso remoto: http://www.guiadohardware.net/guias/10/

Você pode também usar o Samba para compartilhar arquivos do Linux para as máquinas Windows, mas isso já é assunto para outra dica :).

A segunda opção é configurar uma rede ad-hoc entre os dois. A velocidade de transmissão em uma rede ad-hoc é a mesma que em uma rede wireless em modo infra-estrutura (com um ponto de acesso), ou seja, 11 megabits ao usar placas 802.11b ou 54 megabits ao utilizar placas 802.11g, mas o alcance do sinal é bem menor, já que os transmissores e as antenas das interfaces não possuem a mesma potência do ponto de acesso. A velocidade também tende a cair muito mais rapidamente conforme aumenta a distância, embora isso não seja problema caso os dois estejam dentro do mesmo ambiente.

Para criar uma rede ad-hoc no Windows XP, acesse o "Painel de Controle > Conexões de rede". Dentro das propriedades da conexão de redes sem fio, acesse a aba "Redes sem fio" e clique no "adicionar". Na tela seguinte, defina o SSID da rede ad-hoc, marque a opção "Esta é uma rede de computador (ad hoc); não são usados pontos de acesso sem fio":

ad-hoc1Assim como ao configurar um ponto de acesso, você pode ativar o uso de encriptação. O modo mais compatível é escolher a opção "Aberta(o)" na opção "Autenticação de rede" e usar a opção "WEP" na opção "Criptografia de dados", definindo uma chave de acesso (desmarque a opção "Chave fornecida automaticamente").
Embora tanto as chaves WEP de 64, quanto as de 128 bits sejam vulneráveis, é sempre recomendável usar chaves de 128 bits, que são um pouco mais difíceis de quebrar. A chave pode conter 13 caracteres ASCII (letras, números e caracteres especiais) ou 26 caracteres em hexa (números e as letras de A a F). Se preferir definir uma chave de 64 bits, use 5 (ASCII) ou 10 (hexa) caracteres. O WEP é fácil de quebrar, mas os risco é minimizado devido ao alcance reduzido da rede ad-hoc. Se a segurança não for uma prioridade, esta é a configuração recomendável.

Depois de criar a conexão ad-hoc no primeiro PC, ela passa a aparecer para o segundo na lista de redes disponíveis (o ícone ao lado do relógio), permitindo que ele se conecte ao primeiro, após fornecerem a chave de encriptação.

Continuando, a maior parte dos utilitários de configuração de rede wireless no Linux suportam também o uso de redes ad-hoc. Ao usar o Ubuntu, Kubuntu ou outra distribuição que utilize o network-manager, por exemplo, a rede ad-hoc aparece na lista de redes disponível e você pode se conectar diretamente depois de fornecer a passphrase. É possível também criar uma nova rede ad-hoc usando a opção "Criar nova rede sem fio" na janela de seleção de rede, indicando o SSID, o sistema de encriptação e a passphrase desejados:

É possível também configurar a rede em modo ad-hoc via linha de comando. Comece logando-se como root e rode o comando "cat /proc/net/wireless" para verificar como o sistema detectou sua placa wireless (dependendo do chipset usado, ela pode ser vista como eth1, wlan0, ath0 ou ra0)

Comece ativando a placa usando o comando "ifconfig $placa up", seguido do comando do iwconfig que coloca a placa em modo ad-hoc, como em:

# ifconfig eth1 up
# iwconfig eth1 mode Ad-Hoc

O próximo passo é definir o SSID da rede, dessa vez usando o parâmetro "essid" do iwconfig, como em:

# iwconfig eth1 essid gdh

Falta agora definir a chave de encriptação. Ao usar uma chave WEP contendo caracteres ASCII, use o parâmetro "key restricted s:", seguido pela chave, como em:

# iwconfig eth1 key restricted s:minhachave123

Se for usada uma chave contendo caracteres em hexa, remova o "s:", especificando a chave diretamente, como em:
# iwconfig eth1 key restricted 1234567890
Com isso a rede ad-hoc está configurada. Falta apenas ajustar os endereços. Para definir o endereço e a máscara manualmente, use:
# ifconfig eth1 10.0.0.1 netmask 255.0.0.0 up

Estes mesmos comandos podem ser usados para criar uma nova rede ad-hoc, quanto para conectar a máquinas Linux a uma rede já existente (caso o outro micro rode Windows e você tenha criado a rede nele, por exemplo). Como a rede ad-hoc usa um sistema ponto a ponto, você precisa apenas fazer a mesma configuração em todos os micros. Eles são comandos genéricos, funcionam em todas as placas, sem depender de nenhum utilitário adicional.

Continuando, caso o micro Linux tenha duas interfaces de rede, você pode compartilhar a conexão com o outro micro, conectado à rede ad-hoc usando os três comandos abaixo. Note que o "eth0" é a interface da rede cabeada (ou a interface onde está a conexão) e não a placa wireless:
# modprobe iptable_nat
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

O terceiro comando diz que quando um dos PCs da rede ad-hoc tentar acessar a web, os pacotes devem ser encaminhados para a placa eth0, que no exemplo é a interface da rede local. Como no exemplo não instalamos um servidor DHCP, é necessário configurar manualmente os endereços dos PCs da rede ad-hoc, configurando-os para usar o micro Linux como gateway e os endereços DNS do provedor.

No caso do Windows, você pode compartilhar a conexão clicando sobre a placa cabeada (onde está a conexão) dentro do Painel de controle > Conexões de rede e marcando a opção Avançado > Permitir que outros usuários da rede se conectem pela conexão deste computador à Internet. Veja mais detalhes no tutorial sobre configuração da rede no Windows.

hackeando senhas no XP

Introdução

O Windows XP é relativamente robusto e estável, além de oferecer muitas opções de configuração. Deveria ser seguro nas mesmas proporções, mas, infelizmente, não é isso o que acontece. Uma vez precisei da senha de administrador de uma instalação do meu Windows 2000, pois instalei às pressas e não anotei a senha. Para meu uso diário, fiz uma conta limitada, mas, um belo dia precisei me logar como administrador para instalar os drivers da webcam. Aí começou a dor de cabeça: e agora, que senha eu usei na instalação?

Percorrendo a Internet, não demorou muito para encontrar a solução. No Windows NT/2000, para contas locais, basta apagar os arquivos SAM e SAM.log, da pasta C:WINDOWSsystem32config. Comentei isso na época no meu blog (http://janelasepinguins.blogspot.com/2005/10/hackeando-as-senhas-no-windows-2000.html).

Aproveitando a solução, testando no Windows XP, não funcionava: o sistema ficava inacessível após a remoção destes arquivos, e nem iniciava mais. Ou seja, isso foi detectado e corrigido no Windows XP, mas não no 2000, pelo menos, não até o Service Pack 4.

Qualquer um pode ser administrador!


Recentemente, recebi pela área de envio de dicas de um dos meus sites, uma dica bem rápida, aproveitando-se de um recurso do Windows XP para obter acesso como administrador. Deixo então o agradecimento pela colaboração do Rhadsclei, que me passou a idéia e o nome do arquivo envolvido, e decidi comentá-la neste texto, detalhadamente.

O Windows XP usa uma conta especial do sistema, chamada "SYSTEM". Essa conta é usada enquanto nenhum usuário está logado, pois para os programas funcionarem no Windows NT, eles precisam de uma conta de usuário, e usarão as configurações de personalizações e segurança do perfil desse usuário. Mesmo após o logon, se você abrir a guia "Processos" do Gerenciador de tarefas, verá que alguns programas são executados por essa conta, "SYSTEM". Possivelmente são serviços essenciais inicializados antes do ponto de logon, onde há interação com o usuário. Muito provavelmente esta conta especial é usada durante a instalação do Windows também, após o início da parte gráfica. A "brecha" é que ela possui privilégios administrativos. Qualquer programa rodado com ela, tem direitos de administrador, e pode fazer o que bem quiser no sistema. Eis o segredo: rodar um programa sem fazer logon, usando essa conta. Você me perguntaria: mas como, se antes de fazer logon não tenho acesso a nenhum menu ou meio de chamar programas?

Por vias normais, não. Mas...

O Windows possui ferramentas de acessibilidade, para auxiliar de forma mínima usuários com deficiências motoras e/ou audiovisuais. Ele possui um gerenciador de utilitários, chamado pelo atalho Win+U. Independentemente deste, pode-se ficar segurando a tecla SHIFT por 8 segundos, e então as opções de acessibilidade são abertas. Elas permitem configurar o alto-contraste, o movimento do cursor do mouse via teclado, a emissão de sons em determinadas situações, a piscagem da tela durante a reprodução de um som de sistema (como um "beep", por exemplo), etc. Para permitir que os usuários com necessidades especiais tenham esse auxílio durante o logon, o atalho de ficar segurando SHIFT por 8 segundos funciona também na tela de logon.

Eis o truque, facilmente aplicado: substituir o arquivo que é chamado pelo atalho das opções de acessibilidade por outro executável qualquer. O mais prático é o "cmd.exe", o interpretador de comandos. Basta acessar a pasta system32, renomear (ou apagar) o arquivo "sethc.exe", e então copiar o "cmd.exe" para essa mesma pasta, renomeando a cópia com o nome "sethc.exe". Só isso. Agora, ao segurar SHIFT por 8 segundos, o prompt de comando será aberto. Na tela de logon, como os direitos da conta usada ali são de administrador, o prompt de comando será executado como administrador.

Nota: na tela de logon que lista os usuários, o prompt de comando (ou o arquivo "sethc.exe", mais precisamente) poderá ficar oculto, por trás dela. Para não se atrapalhar e exibi-lo corretamente, alterne para o logon clássico, teclando duas vezes CTRL + ALT + DEL. (No Windows NT, teclar duas vezes CTRL + ALT + DEL não faz com que o sistema seja reiniciado; se você não acompanhou o Windows 2000/XP e só conhece o 9x/Me, é bom saber disso :)

O arquivo pode ser substituído facilmente se o usuário possuir uma conta local, mesmo que restrita, e se o HD estiver formatado em FAT/FAT32. Usando o próprio Explorer pode-se trocar o arquivo, já que ele não fica aberto o tempo todo. Se o HD estiver formatado em NTFS, onde os usuários limitados não têm permissão de escrita nas pastas de sistema do Windows, e/ou se o usuário for um intruso que não possui sequer conta local, basta usar um sistema alternativo, que rode do CD. O mais comum é o Linux, diversas distros, como o Kurumin :) Isso considerando que o sistema possa ler e escrever em NTFS, o que é o caso do Kurumin 7.

Rodando o prompt de comando como administrador, você pode chamar programas, que serão executados com privilégios de administrador. Rode "control userpasswords2" para criar novos usuários ou redefinir a senha de qualquer conta de usuário, incluindo, é claro, do administrador.

Se preferir, use o console de gerenciamento do computador (compmgmt.msc), e clique em "Usuários e grupos locais". Eu me surpreendi, pois foi possível rodar até o Explorer! Veja alguns screenshots. Para decepção dos usuários que confiam tanto na segurança do Windows, saiba que estas imagens não foram montadas num programa gráfico, foram todas obtidas com o famoso "Print Screen", salvas originariamente no Paint, também rodando sem fazer logon:
win_html_11008a51
Ao dar o comando "explorer.exe" no prompt, o Explorer foi aberto. Na primeira vez, definiu o papel de parede "Alegria", que é padrão, e ainda ofereceu o "Tour do Windows". Observe a tela de logon arrastada para o topo. Nenhuma senha foi necessária.
win_html_m71dcafc1Criação de uma nova conta de usuário, com o comando control userpasswords2.
win_html_23667545
Ao dar CTRL+ALT+DEL, abriu-se o Gerenciador deTarefas. Pelo visto, ele ficou instável :( Isso ocorreu com alguns outros programas também. No entanto, após criar uma conta e se logar com ela, o acesso ao sistema ficava "normal".
win_html_m23d47eb3
Clicando com o direito na área de trabalho e em "Propriedades", pode-se alterar os temas. Veja, deixei o prateado para a tela de logon! Até que esta dica pode ser útil para mera personalização, você altera as opções visuais da tela de logon sem precisar tocar no registro.


Percebi alguns problemas de estabilidade ao rodar programas deste modo, como no gerenciador de tarefas, o copiar/colar arquivos pelo Explorer não funcionava, etc. Depois de uns 5 minutos o Explorer era fechado sozinho, não sei se isso foi programado ou se é devido algum erro não esperado. Afinal não é esperado "fazer logon sem fazer logon", com a conta de usuário SYSTEM. Mas ele podia ser aberto a qualquer momento, digitando-se "explorer" no prompt de comando novamente.

Talvez isso possa ser usado também no Windows Server 2003, visto que possui muita coisa herdada do XP. Eu não testei, mas me deu uma vontade danada de instalá-lo só para testar. Se funcionar, a Microsoft pisou na bola legal com os usuários dos servidores, afinal isso num servidor é inaceitável. Como não testei, não posso dizer muito, além de meras "premonições". Eu estava usando o Windows XP SP1, e coloquei o SP2 só para ver se o problema permanecia nele. Afinal, se tivesse sido corrigido, eu nem me atreveria a escrever este texto. "Pode ser" que alguma das atualizações automáticas tenha corrigido isso, eu não sei porque não uso o computador principal com Internet, portanto, nada de atualizações automáticas. Mas acredito que não, senão esta falha já teria vazado muito mais amplamente.

E como se proteger?


Uma dica para proteção, caso você tenha computadores com Windows XP na empresa (ou em qualquer lugar que seja), e queira se prevenir, é usar o "syskey". Ele é um programinha não documentado que vem com o Windows, e permite alterar a forma de criptografia das contas de usuários locais. Você pode configurar o Windows para solicitar uma senha especial, independentemente de qualquer conta de usuário, a toda inicialização. Se quiser mais proteção, pode requerer um disquete obrigatório. Sem ele, não se usa o Windows. Para isso basta abrir o SysKey, digitando syskey no "Executar".
win_html_m4f6ef1b2
Tela do SysKey. Clique em "Atualizar" para alterar a proteção do sistema das contas de usuários. Não perca a senha nem o disquete, se for o caso, senão, adeus contas de usuários (mas os arquivos permanecem em C:Documents and settings). Você poderá instalar o Windows do zero em outra pasta, mas perderá acesso a qualquer arquivo criptografado em partições NTFS (se você possuir arquivos protegidos desta forma, é claro).

Pelo menos em teoria, ao ativar a criptografia do banco de dados de contas de usuários dessa forma, o Windows não tem como permitir o logon de ninguém, simplesmente porque não tem as informações das contas, que estariam codificadas na senha especial ou no arquivo do disquete. Pelo que testei, o atalho de segurar SHIFT por 8 segundos não funcionou na tela que pede a senha especial (do syskey). Uma outra idéia, complementar a esta e que não deve ser usada sozinha, é remover ou trocar o arquivo "logon.scr", na pasta system32, a proteção de tela padrão. Os efeitos poderiam ser parecidos se o usuário substituisse esse arquivo pelo prompt de comando, e esperasse ansiosamente por 10 minutos na tela de logon. Para quem não sabe, uma proteção de tela é um arquivo executável, com a extensão ".scr" (eles possuem diferenças técnicas sim, com relação aos ".exe"; mas se você renomear um ".exe" para ".scr", verá que funciona da mesma forma).

A responsabilidade é de cada um


Algumas pessoas particularmente me criticam por escrever "dicas" com este teor. Em meio a tantos agradecimentos e comentários, recebi algumas críticas de revoltados com um texto que escrevi há um tempo sobre criação de vírus (http://janelasepinguins.blogspot.com/2006/08/dica-como-criar-um-vrus.html). Não nego que tive um gostinho de atrair lammers, me divirto com as pessoas que acham que sabem de tudo só por seguirem uma receita que mal entendem como funciona. Lá na frente, um dia, elas têm que encarar uma situação e se ferram. Mas muita gente reconheceu o lado importante da matéria (como os vírus são criados, como agem, como se defender, o que fazer, etc). Provavelmente receberei críticas quanto a este texto, mas os que criticam negativamente são usuários que vão contra o bem comum, ao compartilhamento da informação. Matei a cobra e mostrei o pau, "travei o pc mas mostrei no gerenciador de processos quem foi o culpado". Quanto mais esta informação for divulgada, mais gente se cuidará e, de certa forma, pressionará a empresa produtora do Windows a rever algumas coisas nos seus sistemas antes de soltá-los. Vai dizer que o Tio Bill não sabia que durante a tela de logon a conta usada possui privilégios administrativos? Tudo bem, errar é humano. Antes divulgar esta informação de forma clara e técnica e permitir que mais técnicos e profissionais de TI se mexam para proteger os sistemas dos seus clientes, do que não divulgá-la, ocultá-la. Ela não ficará oculta, um passa para o outro, e se nada for feio para tentar proteger os sistemas, muitos espertinhos se aproveitarão desse mole que o Windows dá. Alunos em escolas e bibliotecas, clientes em lan houses, funcionários em empresas, e até mesmo - porque não? - o seu filho, no seu computador.

Além dessa questão, é uma mão na roda para quem precisa recuperar a senha pessoal, ou criar uma nova conta de usuário, se perder acesso por qualquer motivo às configurações do computador. Uma dica que deve fazer parte da mala de ferramentas de qualquer técnico Windows que se preze. Engraçado que um bom técnico Windows deve ter um live-CD do Linux, não é?

Concluindo


Isso mostra que a senha de administrador no Windows XP e nada é a mesma coisa. Como o software é fechado, a comunidade não pode fazer nada, devendo esperar por um patch da Microsoft. Isso "se sair". Enquanto isso, o Windows em casa ou no escritório, não está seguro. A idéia é de que a conta de administrador é segura, potente, de que realmente o sistema está protegido. Mas não é isso que ocorre. O acesso local, quando possível, é uma das formas mais fáceis de invadir um computador alheio. Portanto, pense em soluções físicas de proteção. Gabinetes com cadeado, câmeras de segurança onde tiver computadores importantes... Só para não falar da segurança paranóica aplicada em data-centers (paranóica, mas essencial!). Enfim, cuide-se.