SQL Injection, como prevenir falhas de segurança em PHP / MySQL

Posted by chavesfop | Artigo, Hacking, Programação | Tuesday 7 July 2009 11:44

O QUE É SQL INJECTION ?

A técnica de injetar um código malicioso em um trecho de código de tratamento SQL.
A maioria das tentativas de SQL Injection irão ser realizadas em um input form, de seu código html, mas também podem ser manipuladas atraves das urls de seu site.

O comando mais básico de SQL Injection é parecido com este:

	Variável' or 1=1--

Vamos supor agora que temos um form de login, e que ele irá receber esta variável na forma em que foi escrita, sem nenhum tratamento.

Portanto, o código SQL que seria executado ficaria assim:

SELECT * FROM users WHERE username = 'Variável' or 1=1--'

Viu como o código serve como uma luva no nosso SQL Injection :D ? O resultado irá nos dar acesso a um usuário, levando em conta que retornara verdadeiro, porque ? porque 1=1.

E o ‘–’ ? Isto serve para dizer ao SQL que ele irá ignorar qualquer outro comando SQL que foi colocado no final, portanto isso ira garantir que nenhum outro código SQL feito na programação interfira em nosso SQL Injection.

Algumas outras sintaxes comuns de SQL Injection são:

    ') or ('1'='1
    "or "1"="1
    ' or '1'='1
    Or 1=1--
    " or 1=1--
    ' or 1=1--

SQL INJECTION, ATACANDO ATRAVÉS DE URLS:

Você sabia que é possivel fazer um ataque de SQL Injection através de URLs ? E isso com certeza é mais perigoso. Geralmente quando utilizamos PHP + SQL, nossas urls ficam no formato:

http://YourWebsite.com/login.php?id=2

e adicionando o código sql ao final da url poderia ficar assim:

http://YourWebsite.com/login.php?id=2‘; DROP TABLE login; #

o caracter # é que nem o — que utilizamos anteriormente…

TÉCNICAS DE PREVENÇÃO DE SQL INJECTION

Editando o tamanho das nossas forms:
Isto apenas irá dar um trabalho a mais ao atacante, neste caso ele teria que refazer os formulários, removendo o tamanho, levando em consideração que os forms são feitos em html puro, portanto qualquer um pode ver seu código…

Validação do tipo de dado:
Uma outra boa idéia é fazer a verificação de dados, quando são digitados na form, portanto, se houver caracteres estranhos, como ‘, ; ou até mesmo um #, já pode acusar erro e não executar o código SQL :D

Privilégios de usuários:
Uma técnica que deve ser praticada também é de nunca acessar o banco de dados como root, e sim como um usuário que tenha certos privilégios, por exemplo, para pesquisas podemos fazer um usuário que seja apenas leitura, assim quando entramos com dados na form, mesmo que seja executado um comando sql malicioso, o usuário ira apenas poder ler dados, impedindo-o de inserir ou deletar registros.

A Verdadeira solução:
Utiliza-se a função ‘mysql_real_scape_string();’, veja como ele funciona:

 $name = "John";
    $name = mysql_real_escape_string($name);
    $SQL = "SELECT * FROM users WHERE username = '$name'";

portanto, quando um alguém mal intencionado tenta executar o SQL Injection, com esta função ele ficaria da seguinte forma:

    $malcious_input = "' OR 1'";
    // Não se assuste!!
    // Com o uso de mysql_real_escape_string()
    // o seguinte é retornado:
	\' OR 1\'

    // Veja como os contra barras escapam as aspas!
    // Agora usuários não podem colocar dados maliciosos...

CONCLUSÃO:
a função mysql_real_escape_string() – não tem um nome tão incrivelmente mágico, mas estes 24 caracteres são a bondade do SQL Injection, o que salva os programadores descuidados… agora, é só aplicar a teoria em seus projetos ;D

  • Share/Bookmark

XDMCP

Posted by chavesfop | Artigo | Tuesday 23 June 2009 10:06

X Display Manager

O que é o X ?
É um software de sistema ou de rede, que oferece ao usuário uma interface gráfica. Portanto ele oferece os recursos básicos de uma interface gráfica, tais como, arrastar janela, fazer imagens de bitmap e outras funções básicas de GUI.
No Linux, as principais interfaces gráficas rodam em cima do X, tais como: KDE, Gnome e XFCE.

X Display Manager Control Protocol

Eu sempre busco a melhor maneira de utilizar o Linux, tanto no trabalho como em casa. E uma das grandes vantagens disso tudo, é que eu posso estar reutilizando desktops antigos, como Pentium II, Pentium e até mesmo um 486 como um terminal de X. Utilizando o X e o XDMCP, podemos então montar uma solução de baixo custo para nossa casa ou trabalho. E o melhor de tudo, isto é GRATUITO, e como sigo minha filosofia Free Software de ser, estou aqui dividindo este conhecimento com vocês, sem falar que você estará deste jeito, ajudando o meio ambiente :D .

Recentemente, algumas distribuições, como o Ubuntu, dão a opção de fazer esta configuração por interface gráfica, mas eu, como um bom Slacker, irei fazer uma configuração a moda antiga, para fins didáticos. E outra em interface gráfica, para não ter mistérios.

Funcionamento do XDMCP:

O servidor X (interface gráfica) é geralmente iniciado com um gerenciador de usuários e interfaces gráficas (aka Display Manager), no qual iremos digitar o usuário que queremos entrar e escolher o gerenciador de janelas de nossa preferência.

Quase todas as distribuições Linux, já incluem em seu sistema um Display Manager, como o XDM, KDM e GDM. Irei utilizar para explicar os exemplos o KDM e GDM. Portanto, quando o Display Manager é iniciado, ele pode operar de duas formas:
- Ele pode gerenciar o X server rodando na maquina local, que no caso iria ser especificado em “Xservers”.
- Pode gerenciar Xservers remotos (tipicamente Xterminals) utilizando o XDMCP como especificado no arquivo “Xaccess”.

Vantagens do X:

1- É possível abrir vários servidores X e rodar não apenas aplicativos, mas também gerenciadores de janelas diferentes em cada um. Sim, você pode rodar o KDE e o Gnome, junto com o XFCE e o Blackbox, todos ao mesmo tempo. :)

2- Os servidores X não estão limitados a rodar aplicativos locais, eles podem rodar aplicativos a partir de qualquer micro da rede, ou mesmo de outros hosts da Internet. Este sistema de compartilhamento do X é chamado de XDMCP.

3- Ao rodar aplicativos remotamente a carga fica toda com o servidor. O cliente utiliza um mínimo de processamento, já que basicamente se limita a enviar os dados recebidos via rede para a tela. Usando um 486 com 8 MB de RAM já é possível ter um terminal X funcional.

4- Ao contrário do VNC, o X consegue uma velocidade de atualização de tela muito boa, mesmo em uma rede de 10 megabits. A principal diferença é que enquanto o VNC transmite a tela na forma de uma imagem, o X transmite apenas texto, com as instruções necessárias para o cliente montar as janelas. Apenas figuras e ícones são transmitidos na forma de imagem.

Configurando o servidor:

Nas distribuições que utilizam o KDM (como o Kubuntu e o Mandriva), procure pelos arquivos kdmrc e Xaccess (que sempre ficam na mesma pasta). Em algumas distribuições (como no Mandriva) eles ficam na pasta “/usr/share/config/kdm/” e, em outras (como no Kurumin e outras distribuições derivadas do Debian), ficam na pasta “/etc/kde3/kdm/“. Você pode usar o comando “locate” para encontrá-los.

Dentro do arquivo “Xaccess“, descomente a linha:

# * #any host can get a login window

Basta retirar a tralha (#), fazendo com que o asterisco seja o primeiro caractere. Esta linha faz com que o servidor passe a aceitar conexões de todos os hosts da rede. Caso você prefira limitar o acesso a apenas alguns endereços (mais seguro), basta substituir o asterisco pelos endereços desejados.

Um pouco mais abaixo, no mesmo arquivo, descomente também a linha abaixo, novamente retirando a tralha:

# * CHOOSER BROADCAST #any indirect host can get a chooser
Xaccess
Xaccess

Esta linha é opcional. O Chooser Broadcast permite que os clientes contatem o servidor para obter uma lista de todos os servidores XDM disponíveis na rede (você pode ter mais de um, como veremos a seguir). Isso é feito usando o comando “X -indirect“.

Em seguida, edite também o arquivo kdmrc. Quase no final do arquivo você encontrará a linha:

[Xdmcp]
Enable=false

Basta alterá-la para:

[Xdmcp]
Enable=true

======================================================

Nas distribuições que utilizam o GDM (o gerenciador de login do Gnome), como o Ubuntu, Fedora, CentOS e diversas outras, a configuração é mais simples, pois o XDMCP pode ser ativado através do configurador da tela de login, o gdmsetup.

Acesse-o executando o comando como root, ou através do “Sistema > Adminstração > Tela de Login” (Sistema > Administração > Janela de início de sessão” no Ubuntu). Acesse a aba “Remoto” e, dentro da opção “Estilo” mude a opção de “Início de sessão remota desabilitada” para “Simples com o navegador de faces”. Esta simples alteração faz com que o XDMCP seja ativado, com o uso da tela de login simplificada, que pode ser configurada a seu gosto:

gdmsetup

gdmsetup

conexao

conexao

Acessando a opção “Configurar XDMCP” você tem acesso a um segundo menu de configuração, que permite definir o número máximo de clientes simultâneos (opção “Máximo de sessões remotas”), que pode ser ajustado de acordo com o número de clientes na rede, ou de acordo com os recursos de hardware do servidor.

Para que as alterações entrem em vigor (tanto no KDM quanto no GDM), é necessário reiniciar o gerenciador de login. Para isso, mude para um terminal de texto (Ctrl+Alt+F2) e reinicie o serviço responsável pelo gerenciador de login, como em:

# /etc/init.d/kdm restart

(ao usar o KDM)

# /etc/init.d/gdm restart


ou

# service dm restart

(no Mandriva)

A partir daí, os terminais já poderão abrir a tela de login do servidor através do comando “X -query IP_do_servidor“, como em:

# X -query 192.168.1.1

O comando deve ser dado com o terminal em modo texto. Se o cliente já estiver com uma sessão do X aberta, ou você desejar abrir mais de uma tela do servidor ao mesmo tempo, basta adicionar o parâmetro “:2″, como em:

# X :2 -query 192.168.1.1

O comando abrirá um segundo terminal gráfico, independente do primeiro, exibindo a tela de login do servidor. Você pode alternar entre os dois usando as teclas Ctrl+Alt+F7 e Ctrl+Alt+F8. Para abrir mais terminais, basta substituir o “:2″ por um número de 3 em diante.

Para automatizar o processo, fazendo com que o terminal abra automaticamente a tela de login do servidor no final do boot, sem passar pelo login local e sem a necessidade de digitar este comando a cada boot, edite o arquivo “/etc/inittab” (no terminal, como root) e altere a linha “x:5:respawn:/etc/X11/prefdm -nodaemon“, que estará no final do arquivo para “x:5:respawn:/etc/X11/X -query IP_do_servidor”, como em:

x:5:respawn:/etc/X11/X -query 192.168.1.1

Isso faz com que o terminal aborte o carregamento do ambiente gráfico local e abra a tela de login do servidor via XDMCP. Este é um velho truque para aproveitar micros antigos, transformando-os em terminais burros. Eu cheguei a usar um Thinkpad 560 como segundo micro durante um bom tempo entre 1998 e 2000 (época em que os notebooks ainda eram muito caros), graças ao XDMCP. Ele era um simples Pentium 100 com 16 MB de RAM e por isso era muito limitado para rodar programas localmente, mas funcionava muito bem como terminal.

Continuando, uma segunda opção é utilizar o comando “X -broadcast” em substituição ao “X -query”. A diferença é que enquanto o X -query exige que você especifique o endereço IP do servidor, o X -broadcast é automático, ele se encarrega de emitir um pacote de broadcast na rede e contatar o primeiro servidor X que responder ao chamado. O “X -broadcast” é sempre usado sem argumentos, como em:

# X :2 -broadcast

Se você tiver mais de um servidor XDM na rede, uma terceira opção é usar o comando: “X -indirect IP_do_servidor“. Nesse caso, você se conectará a um servidor X configurado, mas, ao invés de obter a tela de login automaticamente, terá um menu com todos os servidores X disponíveis na rede e poderá escolher qual usar a cada sessão. A partir daí o cliente escolhe a qual servidor deseja se conectar a cada boot.

Para que o servidor forneça esta lista é preciso que a linha “* CHOOSER BROADCAST” do arquivo Xaccess esteja descomentada (no KDM), ou que a opção “Honrar pedidos indiretos” esteja ativada no gdmsetup (ao usar o GDM).

Um pequeno truque não documentado é substituir o endereço do servidor pelo endereço da rede, como em “X -indirect 192.168.0.0“. Isso faz com que o pedido de listagem vá para todos os servidores XDM da rede. A vantagem é que o cliente não fica preso a um servidor específico; o cliente sempre conseguirá obter a lista, mesmo que apenas um dos servidores da rede esteja ligado.

A principal vantagem de utilizar o XDMCP é que não é preciso instalar nenhum software adicional no servidor nem nas estações, apenas fazer a configuração necessária. Uma vez conectadas no servidor, as estações utilizam automaticamente a conexão com a web, impressora, gravador de DVD, scanner, etc. instalados nele. Não é necessário configurar os compartilhamentos de impressora e conexão, já que, na verdade, tudo é acessado “localmente” dentro do servidor. A unica diferença é que neste caso as imagem são enviadas às estações, ao invés de serem exibidas no monitor do servidor.

O mesmo acontece com relação aos arquivos. Tudo que é aberto e salvo não sai do HD do servidor. Você pode criar um login de usuário para cada um que for acessar o servidor, assim cada um terá onde armazenar seus arquivos e suas configurações e você precisará fazer backup de um único local. Um único servidor, com um processador razoável, rede de 100 megabits e 1 GB de RAM, pode facilmente atender a 20 estações simultaneamente.

Uma última peculiaridade do X é a forma estranha como é definido quem é o cliente e quem é o servidor. O servidor X cuida do acesso ao hardware, da criação de janelas, leitura do teclado, etc. Ele envia estes dados aos programas (o que inclui o gerenciador de janelas), que são chamados de clientes X e estes devolvem as imagens e outros dados que serão mostrados na tela.

Enquanto você está trabalhando localmente, isso parece bastante lógico. Afinal, o servidor X é o intermediário entre o hardware e os programas, que são os clientes. No entanto, a coisa começa a ficar um pouco mais estranha quando começamos a trabalhar em rede.

Se você usa um 486 como um “cliente” que roda aplicativos de um “servidor” remoto, chamamos o 486 de cliente e o servidor de servidor para que fique mais claro a função de ambos. Afinal, o 486 está servindo quase que como um mero terminal burro, que se limita a mostrar imagens no monitor.

Contudo, tecnicamente falando, o servidor X está rodando no 486, já que é ele quem está com o monitor, teclado, etc. O “servidor de rede”, nesse caso, entra apenas com as imagens que serão exibidas por este servidor X (no 486), ou seja, faz o papel de cliente. Este é um ponto confuso, onde é preciso prestar atenção para não trocar as bolas.

Referencias:

http://tldp.org/HOWTO/XDMCP-HOWTO/index.html

http://www.guiadohardware.net/tutoriais/configurando-servidor-xdmcp/

1- É possível abrir vários servidores X e rodar não apenas aplicativos, mas também gerenciadores de janelas diferentes em cada um. Sim, você pode rodar o KDE e o Gnome, junto com o XFCE e o Blackbox, todos ao mesmo tempo. :)

2- Os servidores X não estão limitados a rodar aplicativos locais, eles podem rodar aplicativos a partir de qualquer micro da rede, ou mesmo de outros hosts da Internet. Este sistema de compartilhamento do X é chamado de XDMCP.

3- Ao rodar aplicativos remotamente a carga fica toda com o servidor. O cliente utiliza um mínimo de processamento, já que basicamente se limita a enviar os dados recebidos via rede para a tela. Usando um 486 com 8 MB de RAM já é possível ter um terminal X funcional.

4- Ao contrário do VNC, o X consegue uma velocidade de atualização de tela muito boa, mesmo em uma rede de 10 megabits. A principal diferença é que enquanto o VNC transmite a tela na forma de uma imagem, o X transmite apenas texto, com as instruções necessárias para o cliente montar as janelas. Apenas figuras e ícones são transmitidos na forma de imagem.

  • Share/Bookmark

TFTP

Posted by chavesfop | Artigo | Friday 19 June 2009 11:22

Trivial File Transfer Protocol.

O Trivial File Transfer Protocol (ou apenas TFTP) é um protocolo de transferência de dados, muito simples, semelhante ao FTP.

O TFTP é usualmente utilizado para transferir pequenos dados entre “hosts” numa rede, tal como quando um terminal remoto ou um cliente inicia o seu funcionamento, a partir do servidor.

Algumas caracteristicas do TFTP:
-É baseado em UDP (usa a port 69) ao contrário do FTP que se basea no TCP (usa a port 21);
-Ele não lista os dados de um diretorio;
-Ele não tem mecanismos de encriptação ou autenticação;
-É utilizado para ler ou escrever arquivos de um servidor remoto;
-Devido a sua pouca segurança, o TFTP é perigoso de se usar via Internet, portanto o seu uso geralmente é aplicado apenas em redes locais ou privadas.

Exemplo de uma seção TFTP:
O host A envia um pacote de pedido de leitura (RRQ) ou de pedido de escrita (WRQ) para o host S atravez da conhecida porta 69 (hot) , contendo o nome do dado e o tipo de transferencia.

S responde com um pacote de reconhecimento (ACK) para o pacote de escrita e  diretamente com o dado para o pacote de leitura. Host S envia os pacotes para uma porta recem alocada no host A, e todos os outros pacotes a partir deste momento serão enviados para aquela porta.

O host de origem (neste caso o A) envia pacotes de dados numerados para o host de destino (S), sendo que o ultimo pacote é um pacote de tamanho total (512 bytes), o host de destino responde com pacotes de reconhecimento numerados para cada pacote de dado recebido.

O pacote final de dados, e enviado com um tamanho menor do que o de bloco total (menor que 512 bytes), caso o pacote de dados seja multiplo do valor total, ele enviara um pacote de dados de tamanho 0, apenas para identificar que a transferencia foi completada.

O receptor responde a cada dado com o seu pacote de reconhecimento associado, quando o remetente (quem esta enviando os dados) recebe estes pacotes de reconhecimento, ele imediatamente responde com o proximo pacote de dados.

Se, eventualmente, um pacote de reconhecimento não for recebido, o remetente envia novamente o pacote de dados.

Exemplos de utilização do TFTP:
Quando fazemos o boot em um servidor LTSP, após iniciarmos a maquina utilizando como boot o PXE, recebemos o ip por DHCP, então a imagem do sistema de arquivos do Linux é gravado na memória RAM do cliente, porém… como esta imagem vem até o cliente?
Simples meu amigo… TFTP. :D

Exemplo de configuração no Linux (debian):
pacote: atftp
http://www.vivaolinux.com.br/dica/Configuracao-do-servidor-TFTP/

Referencias:
http://pt.wikipedia.org/wiki/Trivial_File_Transfer_Protocol

http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol

http://www.vivaolinux.com.br/dica/Configuracao-do-servidor-TFTP/

  • Share/Bookmark

PXE

Posted by chavesfop | Artigo | Monday 15 June 2009 11:40

Pre-boot eXecution Environment.

O Ambiente de Pré-execução (PXE ou ‘pixie’, ambos do inglês: Preboot eXecution Environment) é um ambiente para inicializar computadores usando a Interface da Placa de Rede sem a dependência da disponibilidade de dispositivos de armazenamento (como Disco Rígidos) ou algum Sistema Operacional instalado.

Funcionamento:
Um cliente tenta localizar um serviço de redirecionamento de PXE na rede (como um proxy DHCP) com o intuito de receber informações sobre servidores de boot PXE disponiveis. Após receber resposta, o cliente ira perguntar a um servidor de boot apropriado qual o caminho do arquivo ou por um NBP (Network Bootstrap Program), e armazear esta informação dentro da RAM do computador usando o TFTP, apos o armazenamento ele verifica as informações e depois as executa.

Onde uso o PXE ?
Aqui irei dar 2 exemplos muito comuns de uso do PXE
1- Usado em servidores LTSP, o PXE que ira passar as informações para boot dos clientes.
2- Usado para fazer instalação de um distribuição em varias maquinas simultaneamente por rede, como explicado aqui.

Referencias:

http://www.howtoforge.com/setting-up-a-pxe-install-server-for-multiple-linux-distributions-on-debian-lenny

http://pt.wikipedia.org/wiki/Preboot_Execution_Environment

http://www.guiadohardware.net/termos/pxe

  • Share/Bookmark

DHCP

Posted by chavesfop | Artigo | Tuesday 9 June 2009 11:06


Dinamic Host Control Protocol


O que é DHCP:
É um protocolo de serviço TCP/IP que oferece configuração dinâmica de terminais. Uma das varias vantagens do DHCP é que você não precisa definir manualmente o IP dos terminais, o servidor DHCP vai enviar um IP para cada maquina, e pode-se configurar no proprio servidor o tempo de vida desse IP.

O DHCP opera da seguinte forma:
Um cliente envia um pacote UDP para todas as maquinas com um pedido de DHCP, os servidores DHCP que capturarem este pacote irão responder com um pacote de configurações onde constará, pelo menos, um endereço IP, uma mascara de rede, e outros parametros opcionais, como gateway e endereços de DNS.

Criterios de atribuição de IPs:
-Atribuição manual: Onde existe uma relação entre o endereço MAC do cliente e o endereço IP a fornecer. Essa associação é feita manualmente pelo administrador da rede, com isso apenas os clientes cujo MAC consta nesta lista poderão receber configurações desse servidor.

-Atribuição automatica: Onde o cliente obtém um endereço de um espaço de endereços possíveis, especificado pelo administrador. Geralmente não existe vínculo entre os vários MAC habilitados a esse espaço de endereços.

-Atribuição dinâmica: Tem funcionamento parecido com o automatico, porém cada cliente tem um tempo de vida para seu IP, e este tempo começa a expirar assim que o cliente for desconectado da rede, portanto na proxima vez que ele se conectar na rede, se o tempo de vida ainda for valido (maior que zero) ele continuará com o mesmo IP, caso contrario será fornecido um novo IP ao cliente.

Servidor DHCP Linux:
pacote debian-like: dhcp3-server
pacote outras distros: dhcpd

- Configurações necessarias para iniciarmos o serviço:
arquivo dhcpd.conf

ddns-update-style none;
#tempo de vida do IP neste caso 1200 segundos ou 20 minutos
default-lease-time 1200;
#se houver outro servidor dhcp na rede, este sera o preferencial
authoritative;
#especificações da distribuição de IPs
subnet 10.0.0.0 netmask 255.0.0.0 {
   #faixa em que sera distribuidos os ips
   range 10.0.0.1 10.0.0.253
   #especifica o roteador/gateway, no caso pode-se atribuir este
   #ip fixo na maquina que ira rodar o serviço de dhcpd.
   option routers 10.0.0.254
   #especifica os servidores dns que serao usados, lembrar de
   #sempre especificar os servidores dns da rede interna, depois
   #os servidores dns da internet (br. telecom por exemplo).
   option domain-name-servers 10.0.0.254, 201.10.120.3
   #endereço de broadcast
   option broadcast-address 10.0.0.255
}
#exemplo de atribuição de IP fixo a um cliente
host nome_exemplo1 {
   #especificação do MAC address da placa do cliente.
   hardware athernet 00:00:00:00:00:00;
   #endereço de IP que o cliente ira receber.
   fixed-address 10.0.0.2;
}

Referencias:

http://www.vivaolinux.com.br/artigo/DHCP-Configurandoo-de-forma-simples-e-eficiente/?pagina=3

http://pt.wikipedia.org/wiki/DHCP

Minha cabeça… :D

  • Share/Bookmark

A guerra dos browsers

Posted by demoncyber | Artigo, Dicas | Monday 22 September 2008 14:00
Browser Wars

Browser Wars

Este documentário me fez refletir sobre como o chrome pode afetar a historia do mundo da internet mais uma vez assim como  a netscape já o fez, mas agora sem fazer dos erros das outras grandes empresas se sentindo superiores.

Pena o documentário não ser mais atual e trazer outras partes das historias como a influência do catedral e bazar, do Eric Raymond para fazer com que a netscape se tornasse gratuita e assim criando a mozzila, e depois com o Dave Hyatt e Blake Ross que pegou e reformulou o código do mozilla e criou o firefox que cresceu como a netscape dominando mercado, e por fim hoje temos o nascimento do chrome, falta também a historia de browsers importantes que apareceram neste período como safari da mac, konqueror, browsers inovadores como o opera que criou as abas nos browsers, o cliente de torrent integrado sem contar uma ótima ferramenta de downloads e uma aparência sempre muito limpa. Bom quem sabe fica para um próximo.

Documentário alvo do post :)

http://www.discoverybrasil.com/internet/show.shtml

História um pouco mais atualizada da guerra dos browsers

http://en.wikipedia.org/wiki/Browser_wars.html

Agradecimentos Walmer por indicar o vídeo :)

  • Share/Bookmark

A mágica do rsync

Posted by demoncyber | Artigo, Dicas, Linux | Monday 15 September 2008 06:22
SYNC-ME

SYNC-ME

A mágica do rsync
Este artigo apresenta o aplicativo rsync e algumas dicas de como utiliza-lo. Vamos lá!

Rsync de acordo com o wikipedia
rsync is a software application for Unix systems which synchronizes files and directories from one location to another while minimizing data transfer using delta encoding when appropriate. An important feature of rsync not found in most similar programs/protocols is that the mirroring takes place with only one transmission in each direction. rsync can copy or display directory contents and copy files, optionally using compression and recursion” – Wikipedia sobre Rsync

Ok, mas porque rsync é uma solução mais interessante do que copiar os arquivos na mão e quais são as suas vantagens?
- A sua compressão e o algoritmo de transferência delta-transfer aumenta o desempenho para as transferências
- Pode manter todo as permissões do arquivo
- Pode se utilizar de uma transferência de arquivos segura ( via ssh)

Como faço para instalar?

Acesse a página do projeto e baixe o seu código fonte e compile . http://rsync.samba.org/download.html, ou você pode se utilizar de algum pacote pronto para o seu sistema operacional. Atualmente é difícil encontrar algum sistema operacional baseado no UNIX que não traga essa mágica ferramenta por padrão. Em nosso caso vamos tratar da instalação sendo feita em um Debian lenny:

apt-get install rsync

Certo mas como configurar o daemon do rsync?

Bom o rsync tem um arquivo de configuração padrão chamado rsyncd.conf que fica dentro do diretório /etc. Segue um modelo de estrutura do arquivo:
- Ocultar texto das mensagens anteriores -

#/etc/rsyncd.conf

#Opções Globais
uid = nobody
#habilita para usar um usuário com permissões mínimas chamado nobody
gid = nobody
#habilita para usar um grupo com permissões mínimas chamado nobody
motd file = /etc/rsyncd.motd
# arquivo de mensagem do dia quando logar para a transferência de arquivo
log file = /var/log/rsyncd.log
# arquivo de log de copias e do sistema
pid file = /var/run/rsyncd.pid
# arquivo que mantém o pid do daemon
lock file = /var/run/rsync.lock
#arquivo de trava criando para não abrir vários processos do rsync
use chroot=yes
# habilita o uso do change root o que dá um nível mais alto de segurança a cópia do arquivo que está sendo executada

#Opções Globais

#Opções dos caminhos

[nome_do_meu_caminho_compartilhado]
# Nome dado a especificação do caminho compartilhado
path = /rsync_files_here
#caminho compartilhado
comment = Meu diretório compartilhado pelo Rsync
# comentário sobre o caminho compartilhado
read only = yes
# especifica se o compartilhamento é somente para leitura
list = yes
# habilita a listagem do módulo
auth users = username

#Opções dos caminhos

# Fim arquivo /etcrsyncd.conf

O que é mais necessário além de um bom arquivo comentado para explicar o funcionamento? D

Para rodar o daemon do rsync depois do arquivo de configuração pronto somente é necessário usar o parâmetro –daemon.

rsync –daemon

Estrutura do comando para utilização:

rsync [opções] origem destino

Agora vamos a nossa coleção de mágicas

Sincronia de diretório local: rsync -ravzp /home/usuario/ /home/bkp/
Sincronia de arquivos locais para um servidor: rsync -ravzp /home/usuario/ usuario@192.168.0.5:/home/bkp/
Sincronia de arquivos do servidor para uma maquina local: rsync -ravzp usuario@192.168.0.5:/home/bkp/ /home/usuario/
Listando o diretório: rsync -ravzp usuario@192.168.0.5:/home/bkp/

-r recursivo
-a mantém a estrutura de forma idêntica
-v modo de verbose o qual apresentada os dados do que está sendo executado
-z comprime o arquivo durante a transferência ( aumenta a velocidade de cópia )
-p preserva as permissões

Mais explicações sobre os parâmetros pode-se encontrar em man rsync =p

Espero que este Artigo ajude o pessoal a sincronizar os seus projetos, abraços e até a proxima (Demoncyber)

Ferramenta gráfica para sincronização de arquivos grsync

Dados técnicos:
Licença GNU
Porta 873

Site do projeto

http://samba.anu.edu.au/rsync/

Referência:

http://samba.anu.edu.au/ftp/rsync/rsync.html

http://everythinglinux.org/rsync/

http://en.wikipedia.org/wiki/Rsync

http://www.opbyte.it/grsync/

http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=338

http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=8011

http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=882


Marco Carvalho de Oliveira
Ciência da Computação – UDESC – Joinville
COLMÉIA – Grupo de Pesquisa em Software Livre

  • Share/Bookmark

Como verificar as conexões abertas no seu Linux de várias maneiras

Posted by demoncyber | Artigo, Dicas, Hacking, Linux, Programação | Monday 15 September 2008 05:56
CLICK-ME

NO CLICK-ME THIS TIME :/

Este artigo foi publicado no blog do Colméia , no fórum do slackbr e no vivaolinux :) e por fim público aqui

Como verificar as conexões abertas no seu Linux de várias maneiras

Estivemos com um problema em um projeto que precisava verificar se o serviço xdmcp estava aberto, porém ele não é um processo independente, ele fica interligado ao X, kdm, gdm, xdm, para tanto a solução mais cabível era procurar saber se a porta estava aberta na máquina.

Sim, talvez pudesse existir outras maneiras de resolver isso, mas esta se fez mais interessante. A clássica solução que me veio a cabeça foi usar o netstat, mas pensei em porque não ir mais a fundo e como resultado venho por este artigo mostrar algumas coisas que aprendi.

As formas que executei este processo foram:

  • Geek hacker ninja style form – procura no proc pelas conexões abertas (mais interessante e a que mais aprendi);
  • Status network – usa o comando de status de rede para listar;
  • Open Files – Procura baseado nos arquivos abertos o que está ligado a porta.

Geek hacker ninja style form

A forma mais baixo nível e estilosa =], vamos aos arquivos de kernel analisar suas saídas, está é a base utilizada por programas como o netstat, o qual converte os dados deste e mostra com uma saída personalizada. Foi publicado um artigo antes explicando sobre a conversão de bases, então não vou abordar este assunto aqui.

O arquivo em questão utilizado é o /proc/net/tcp.

Exemplo de /proc/net/tcp:

sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode

0: 9E00A8C0:D3FD E1D7BCCD:1F4A 01 00000000:0003163C 00:00000000 00000000  1000        0 383991 1 cb042500 102 12 4 2 100

1: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 626508 1 c299db80 750 0 0 2 -1

Onde:

  • sl: O número de identificador da linha.
  • local_address: O endereço local e o número da porta do socket. O endereço local está codificado em little-endian em quatro seqüências de números em hexadecimal, isso significa que o byte mais importante é listado primeiro e você necessita fazer a inversão da ordem dos bytes para converter para o endereço de IP. O número da porta é um hexadecimal simples utilizado pelo programa.
  • rem_address – O endereço remoto e o número da porta do socket. O endereço local está codificado em little-endian em quatro seqüências de números em hexadecimal, isso significa que o byte mais importante é listado primeiro e você necessita fazer a inversão da ordem dos bytes para converter para o endereço de IP. O número da porta é um hexadecimal simples.
  • st: Status do socket (depois de muita busca encontrei onde estava o padrão de código daqui e o porque do valor ficar com 0A – segue tabela de referência no final).
  • tx_queue rx_queue: O tamanho de transmissão e recebimento das filas de pacotes.
  • tr tm->when: tr é o campo que indica se o medidor de tempo está ativo para este socket. Um valor zero indica que o medidor de tempo não está ativo. O tm->when indica tempo que o sock está sendo utilizado em jiffies (usado basicamente para debug).
  • retrnsmt: Campo de informação interna do socket do kernel (usado basicamente para debug).
  • uid: O uid do usuário dono da conexão.
  • time-out: Campo de informação interna do socket do kernel (usado basicamente para debug).
  • inode: Um número encriptado de identificação do socket para o sistema de arquivos do Linux (não encontrei qual é a criptografia utilizada aqui).

Achei a representação padrão do cat do arquivo /proc/net/tcp muito extensa, então refiz ela na horizontal para melhor explicar o exemplo acima e traduzi alguns dados:

sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode

0: 9E00A8C0:D3FD E1D7BCCD:1F4A 01 00000000:0003163C 00:00000000 00000000  1000        0 383991 1 cb042500 102 12 4 2 100

1: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 626508 1 c299db80 750 0 0 2 -1

sl : 0 – linha indicadora da primeira conexão

local_address: 9E00A8C0:D3FD – convertendo fica 192.168.0.158:151775

rem_address: E1D7BCCD:1F4A – convertendo fica 205.188.215.225:8010

st: 01 – TCP ESTABELISHED – conexão estabelecida

tx_queue rx_queue: 00000000:0003163C – fila de dados transmitidos

tm->when retrnsmt: 00:00000000 00000000 – dados utilizados para debug

uid: 1000 – id do usuário dono da conexão

timeout: 0 – dado utilizado para debug

inode: 383991 1 cb042500 102 12 4 2 100 – identificador criptografado

sl : 1 – linha indicadora da primeira conexão

local_address: 00000000:0016 – convertendo fica localhost:22

rem_address: 00000000:0000 – não tem ninguém conectado

st: 0A – TCP_LISTEN – escutando conexão

tx_queue rx_queue: 00000000:0003163C – fila de dados transmitida

tm->when retrnsmt: 00:00000000 00000000 – dados utilizados para debug

uid: 1000 – id do usuário dono da conexão

timeout: 0 – dado utilizado para debug

inode: 383991 1 cb042500 102 12 4 2 100 – identificador criptografado

Status network

Podemos ver as conexões abertas através do comando netstat. O mesmo é um programa de estatísticas de rede utilizado amplamente para este fim. Não tem muitos segredos e as informações que ele mostra são muito legíveis. Alguém percebeu a similaridade com um outro arquivo no modo que as informações aparecem? :)

# netstat -tl – lista as conexões abertas de tcp em modo de escuta

# netstat -t – lista as conexões tcp estabelecidas

# netstat -p – lista os programas que estão usando a conexão

# netstat –numeric-ports – não converte o número da porta para ser listado

# netstat –numeric-hosts – não converte o número de ip para nome do host

Comando que resolveu meu problema:

# netstat -t -l -p –numeric-ports

Open Files

Vendo as conexões abertas através do comando lsof. O comando lsof lista os arquivos abertos, através disto vamos procurar o arquivo aberto relacionado às portas tcp.

Obs.: Ele pode pegar muitas informações interessantes sobre os arquivos abertos, mas não é escopo deste artigo. :)

Sintaxe: lsof -i protocolo

Exemplo:

# lsof -i tcp

Tabela de dados para o status do socket – versão do kernel 2.6.21.5 Slackware Linux 12

st status socket values
significado valor
TCP_ESTABLISHED 01
TCP_SYN_SENT 02
TCP_SYN_RECV 03
TCP_FIN_WAIT1 04
TCP_FIN_WAIT2 05
TCP_TIME_WAIT 06
TCP_CLOSE 07
TCP_CLOSE_WAIT 08
TCP_LAST_ACK 09
TCP_LISTEN 0A
TCP_CLOSING 0B
TCP_MAX_STATES 0C

Ambiente de teste

  • Slackware 12.0
  • kernel 2.6.21.5

Conclusão

Estas foram apenas algumas maneiras, devem ter mais. Espero que tenham gostado e que algum dia isto seja útil a alguém =], bom para mim foi um grande aprendizado.

(Desculpe qualquer erro de português :X)

Definições

jiffy – medida utilizada para representar o uso de uma tarefa em chamadas de interrupção no processador (medida em um Linux com kernel 2.6.13 em um Intel 386 é de 4 ms ou 1/250 avos de um segundo)

Referências

  • Share/Bookmark
Get Adobe Flash playerPlugin by wpburn.com wordpress themes