DickRips – Informatica e Atualidade

Pagina dedicada ao Linux, Tecnologias e diversidades

Arquivo da categoria ‘Linux’

Apache PHP Postgresql no CentOS e Fedora

Publicado por Daniel Carraro Tomasini em Janeiro 16, 2009

Nesse pequeno tutorial vamos aprender a instalar e configurar de maneira básica um servidor Web na plataforma Linux (baseado no CentOS 5). Note que trata-se de material inédito, que será de grande valia para muitos que, como eu, precisam fazer isso e não encontram materiais disponíveis na web. Mãos à obra!

1) Abra o shell e logue como root:
No CentOS e Fedora o pacote chama-se httpd;

2) Instalando o Apache:
# yum install httpd

Após a instalação, é necessário rodar o comando chkconfig para que ele seja ativado no boot:
# chkconfig httpd on

3) Para iniciar o serviço temos duas opções de comandos:
# service httpd start
OU
# /etc/init.d/httpd start

start: Inicia o serviço
stop: Para o serviço
restart: Para e inicia o serviço
reload: Apenas atualiza a configuração, sem para o serviço.

Após iniciar o serviço, abra o navegador e digite, para testar o serviço:
http://127.0.0.1
Se for carregada a página inicial do APACHE, significa que a instalação foi concluída com sucesso!

Todas as configurações do Apache no CentOS e Fedora ficam no arquivo:
/etc/httpd/conf/httpd.conf

Os sites ficam concentrados dentro do diretório:
/var/www/html/

4) Instalando o suporte a PHP:
# yum install php

5) Instalando o módulo PHP para fazer a junção com Postgresql:
# yum install php-pgsql

Para que as alterações entrem em vigor, reinicie o Apache:
# service httpd restart

Para verificar se o suporte a PHP esta ativo, crie um arquivo com o nome teste.php dentro da pasta /var/www/html/
que contenha a seguinte linha:
<?php phpinfo( ); ?>

Abra o seu navegador e digite o endereço:
http://127.0.0.1/teste.php

6) Instalando o Postgresql com todas as suas dependências:
# yum install postgresql*.*

Iniciando o serviço e ativando-o no boot:
# service postgresql start
# chkconfig postgresql on

Os arquivos de configuração do Postgresql se encontram dentro da pasta:
/var/lib/pgsql/data/

Acesse esse diretório e vamos editar os arquivos de configuração:
# cd /var/lib/pgsql/data
# vi pg_hba.conf

No final do arquivo deixe as linhas conforme o exemplo abaixo:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:

Libera o acesso para a máquina local sem senha:
host all all 127.0.0.1/32 trust

Libera o acesso para a rede local sem senha:
host all all 192.168.0.0/24 trust

# Libera o acesso externo sem senha
host all all 0,0,0,0 0,0,0,0 trust

# IPv6 local connections:

#host all all ::1/128 ident sameuser

Para que as alterações entrem em vigor reinicie o serviço:
# service postgresql restart

Agora vamos editar o arquivo postgresql.conf:
# vi postgresql.conf

Descomente e modifique as linhas abaixo conforme o exemplo:

#—————————————————————————
# CONNECTIONS AND AUTHENTICATION #—————————————————————————

# – Connection Settings -

# Descomente, essa linha faz com que o Postgresql aceite conexões de qualquer ip.
listen_addresses = ‘*’ # what IP address(es) to listen on;

# comma-separated list of addresses;

# defaults to ‘localhost’, ‘*’ = all

# Descomente as linha abaixo,
port = 5432
max_connections = 500

Para que as alterações entrem em vigor reinicie o serviço:
# service postgresql restart

Alguns comandos básicos de Postgresql:

Criando uma base de dados chamada microcamp
# createdb -U postgres microcamp

Listando as bases de dados dentro do banco:
# psql -U postgres -l

Entrando dentro da base de dados microcamp
# psql -U postgres microcamp

# Listando o conteúdo da base de dados:
frigo2=# \d

# Atribuindo uma senha para a base de dados
frigo2=# alter user postgres with encrypted password ’senha’;

Para sair da base de dados use as teclas CTRL + D simultaneamente.

Após atribuido a senha a base de dados é necessário editar novamente o arquivo pg_hba.conf, trocando os métodos trust por md5 para que a senha seja requisitada ao tentar a conexão, lembrando que o arquivo se encontra dentro do diretório /var/lib/pgsql/data.
# cd /var/lib/pgsql/data
# vi pg_hba.conf

# TYPE DATABASE USER CIDR-ADDRESS METHOD

# “local” is for Unix domain socket connections only

local all all md5

# IPv4 local connections:

# Libera o acesso para a máquina local sem senha
host all all 127.0.0.1/32 md5

# Libera o acesso para a rede local sem senha
host all all 192.168.0.0/24 md5

# Libera o acesso externo sem senha
host all all 0,0,0,0 0,0,0,0 md5

# IPv6 local connections:

#host all all ::1/128 ident sameuser

Para que as alterações entrem em vigor reinicie o serviço:
# service postgresql restart

Agora vamos testar a conexão com o Postgresql, crie um arquivo chamado conexao.inc.php dentro do diretório /var/www/html e adicione as linhas abaixo:

<?php

$strConexao=”host=localhost user=postgres dbname=frigo2 password=frigo13579 port=5432″;

$conexao=pg_connect($strConexao);

if(!$conexao){

echo “Erro na conexcao: ” . pg_last_error($conexao);

}

?>

Agora crie um arquivo chamado consultar_todos.php e adicione as linhas abaixo:

<?php

$strConexao=”host=localhost user=postgres dbname=frigo2 password=frigo13579 port=5432″;

$conexao=pg_connect($strConexao);

if(!$conexao){

echo “Erro na conexcao: ” . pg_last_error($conexao);

}

?>

Agora uma dica muito importante, para que a conexão possa ser estabelecida no CentOS é necessário desativar o SELinux, que por padrão na instalação fica ativado, para desativa-lo vá na área de trabalho e no menu Sistema -> Administração -> Nível de Segurança e Firewall e selecione Desativado

Pronto sua configuração básica já vai estar funcionando.

Fonte: www.microcampnews.com.br

Enviado em Linux, Programação, Redes, Servidores, Tecnico | Deixar um comentário »

Wireless: ataques contra o WPA

Publicado por Daniel Carraro Tomasini em Dezembro 23, 2008

Ao contrário do WEP, o WPA e o WPA2 não possuem falhas conhecidas de segurança, que permitam descobrir a chave rapidamente. Apesar disso, ainda é possível usar ataques de força bruta para descobrir passphrases fáceis, baseadas em palavras do dicionário ou sequências numéricas simples. Vamos então entender melhor como o processo funciona.

O primeiro passo é instalar o pacote aircrack-ng, sucessor do pacote aircrack que usamos anteriormente, que contém as ferramentas que utilizaremos.

Para funcionar, ele precisa que a placa wireless suporte o modo monitor, que é suportado por padrão em um número cada vez menor de drivers. Na maioria dos casos, você vai precisar primeiro modificar os drivers da placa, baixando o fonte, instalando um patch e compilando o driver modificado. Para isso, você precisa ter instalados os headers do kernel e os compiladores básicos.

Você pode encontrar informações detalhadas de como fazer isso em conjunto com diversas placas no: http://www.aircrack-ng.org/. Outra opção é utilizar o BackTrack, que já vem com os patches instalados.

Para aplicar o teste, comece usando o Kismet para descobrir o SSID e o canal utilizado pela rede que deseja testar, além do endereço MAC do ponto de acesso e o endereço MAC de pelo menos um cliente que esteja conectado a ele. Se você está testando sua própria rede, basta checar as informações na configuração do ponto de acesso.

O passo seguinte é usar o airmon-ng para capturar o processo de autenticação de um dos clientes da rede. Ele é baseado no uso de um “four-way handshake”, onde uma série de quatro pacotes é usada para negociar uma chave criptográfica entre o cliente e o ponto de acesso, que é então usada para criptografar o processo de autenticação.

Naturalmente, capturar esta sequência de pacotes não permite descobrir a passphrase da rede, mas oferece a possibilidade de executar o ataque de força bruta, testando várias possibilidades até descobrir a chave correta.

Comece colocando a placa wireless em modo monitor, usando o comando “airmon-ng start interface”, como em:

# airmon-ng start eth1

No caso das placas com chipset Atheros, é necessário desativar a interface “ath0″ e recriá-la em modo monitor, usando os comandos:

# airmon-ng stop ath0
# airmon-ng start wifi0

O passo seguinte é capturar o processo de autenticação de um dos clientes. Vamos fazer isso abrindo dois terminais. O primeiro será usado para rodar o airodump-ng e assim capturar as transmissões e o segundo para rodar o aireplay-ng, desconectando o cliente e obrigando-o a se reconectar ao ponto de acesso, de forma que os pacotes possam ser capturados.

No primeiro terminal, ative o airodump-ng, especificando onde será gravado o arquivo com os pacotes capturados, o canal usado pelo ponto de acesso e a interface, como em:

# airodump-ng -w logrede –channel 2 ath0

Com isso, será gerado um arquivo “logrede.cap” no diretório atual.

No outro terminal, rode o comando “aireplay-ng –deauth 1″, especificando o endereço MAC do ponto de acesso (-a) e o endereço MAC do cliente que será desconectado (-c), como em:

# aireplay-ng –deauth 1 -a 00:50:50:81:41:56 -c 00:19:7D:4C:CA:07

Este comando faz com que seu PC envie um pacote falseado ao ponto de acesso, simulando o processo de desconexão do cliente especificado. Enganado pelo pacote, o ponto de acesso desconecta o cliente, o que faz com que ele se re-autentique em seguida, um processo executado de forma automática pela maioria dos sistemas operacionais. Com isso, o processo de autenticação será gravado pela captura iniciada no outro terminal.

Para realizar o ataque baseado em dicionário, é necessário utilizar um arquivo de texto, contendo uma lista das palavras que serão testadas. Existem diversos arquivos de dicionário largamente disponíveis na web (faça uma busca por “wordlists” no Google), como o repositório disponível no http://www.outpost9.com/files/WordLists.html.

Na maioria das distribuições, você encontra também uma lista de palavras que pode ser usada na forma do arquivo “/usr/share/dict/words” e você pode também comprar um CD com uma coleção de arquivos, contendo listas com palavras de todas as línguas no: http://www.openwall.com/passwords/wordlists/.

Com o arquivo de palavras em mãos, use o comando abaixo para testar as combinações, especificando o SSID da rede, o arquivo com as palavras e o arquivo com a captura dos pacotes (gerado pelo airmon-ng), como em:

$ aircrack-ng -e rede -w dict.txt logrede.cap

… onde o “rede” indica o SSID da rede, o “dict.txt” indica a localização do dicionário e o “logrede.cap” é o arquivo com a captura. É necessário indicar o SSID da rede, pois ele é uma das informações incluídas no processo de autenticação.

O teste é feito em modo offline, usando os pacotes de autenticação capturados para simular o processo de autenticação usando cada uma das palavras incluídas no arquivo. O volume de processamento necessário para cada uma faz com que o teste demore um bom tempo. Um Celeron-M de 1.4 GHz, por exemplo, consegue processar (mesmo com todas as otimizações incluídas no aircrack-ng) apenas cerca de 100 possibilidades por segundo, o que resulta em um ritmo de 360 mil combinações por hora, ou 8.64 milhões de combinações por dia.

Pode parecer bastante, mas nesse ritmo demoraria mais de um milhão de anos para testar todas as possibilidades de uma passphrase com 8 caracteres contendo letras, números e caracteres especiais (e exponencialmente mais para passphrases mais longas). É por isso que o ataque se concentra em testar uma lista de palavras, e não em realmente testar todas as possibilidades possíveis.

Fonte: www.gdhpress.com.b

Enviado em Linux, Redes, Segurança | Deixar um comentário »

Especial Linux

Publicado por Daniel Carraro Tomasini em Novembro 20, 2008

Linux é o termo geralmente usado para designar qualquer sistema operacional que utilize o núcleo Linux. Foi desenvolvido por Linus Torvalds, inspirado no sistema Minix. O seu código fonte está disponível sob licença GPL para qualquer pessoa utilizar, estudar, modificar e distribuir de acordo com os termos da licença.

Inicialmente desenvolvido e utilizado por grupos de entusiastas em computadores pessoais, o sistema Linux passou a ter a colaboração de grandes empresas, como a IBM, a Sun Microsystems, a Hewlett-Packard, Novell e a Canonical.

O kernel Linux foi, originalmente, escrito por Linus Torvalds do Departamento de Ciência da Computação da Universidade de Helsinki, Finlândia, com a ajuda de vários programadores voluntários através da Usenet.

Linus Torvalds começou o desenvolvimento do kernel como um projeto particular, inspirado pelo seu interesse no Minix, um pequeno sistema UNIX desenvolvido por Andrew S. Tanenbaum. Ele limitou-se a criar, nas suas próprias palavras, “um Minix melhor que o Minix” (”a better Minix than Minix”). E depois de algum tempo de trabalho no projecto, sozinho, enviou a seguinte mensagem para comp.os.minix:

Você suspira pelos bons tempos do Minix-1.1, quando os homens eram homens e escreviam seus próprios “device drivers”? Você está sem um bom projecto em mãos e deseja trabalhar num S.O. que possa modificar de acordo com as suas necessidades? Acha frustrante quando tudo funciona no Minix? Chega de noite ao computador para conseguir que os programas funcionem? Então esta mensagem pode ser exactamente para você.

Como eu mencionei há um mês atrás, estou trabalhando numa versão independente de um S.O. similar ao Minix para computadores AT-386. Ele está, finalmente, próximo do estado em que poderá ser utilizado (embora possa não ser o que você espera), e eu estou disposto a disponibilizar o código-fonte para ampla distribuição. Ele está na versão 0.02… contudo eu tive sucesso ao executar bash, gcc, gnu-make, gnu-sed, compressão, etc. nele.

Curiosamente, o nome Linux foi criado por Ari Lemmke, administrador do site ftp.funet.fi que deu esse nome ao diretório FTP onde o kernel Linux estava inicialmente disponível (Linus tinha-o baptizado como “Freax”, inicialmente).

No dia 5 de outubro de 1991 Linus Torvalds anunciou a primeira versão “oficial” do kernel Linux, versão 0.02. Desde então muitos programadores têm respondido ao seu chamado, e têm ajudado a fazer do Linux o sistema operacional que é hoje. No início era utilizado por programadores ou só por quem tinha conhecimentos, usavam linhas de comando. Hoje isso mudou, existem diversas empresas que criam os ambientes gráficos, as distribuições cada vez mais amigáveis de forma que uma pessoa com poucos conhecimentos consegue usar o Linux. Hoje o Linux é um sistema estável e consegue reconhecer todos os periféricos sem a necessidade de se instalar os drivers de som, vídeo, modem, rede, entre outros.

O Linux adota a GPL, uma licença livre – o que significa, entre outras coisas, que todos os interessados podem usá-lo e redistribuí-lo. Aliado a diversos outros softwares livres, como o KDE, o GNOME, o Apache, o Firefox, os softwares do sistema GNU e o OpenOffice.org, o Linux pode formar um ambiente moderno, seguro e estável para desktops, servidores e sistemas embarcado.

Distribuições

Atualmente, um Sistema Operacional Linux ou GNU/Linux completo (uma “Lista de distribuições de Linux ou GNU/Linux“) é uma coleção de software livre (e por vezes não-livres) criados por indivíduos, grupos e organizações de todo o mundo, incluindo o núcleo Linux. Companhias como a Red Hat, a SuSE, a Mandriva (união da Mandrake com a Conectiva), bem como projetos de comunidades como o Debian ou o Gentoo, compilam o software e fornecem um sistema completo, pronto para instalação e uso. Patrick Volkerding também fornece uma distribuição Linux, o Slackware.

As distribuições do Linux ou GNU/Linux começaram a receber uma popularidade limitada desde a segunda metade dos anos 90, como uma alternativa livre para os sistemas operacionais Microsoft Windows e Mac OS, principalmente por parte de pessoas acostumadas com o Unix na escola e no trabalho. O sistema tornou-se popular no mercado de Desktops e servidores, principalmente para a Web e servidores de bancos de dados.

No decorrer do tempo, várias distribuições surgiram e desapareceram, cada qual com sua característica. Algumas distribuições são maiores outras menores, dependendo do número de aplicações e sua finalidade. Algumas distribuições de tamanhos menores cabem num disquete com 1,44 MB, outras precisam de vários CDs, existindo até algumas versões em DVD. Todas elas tem o seu público e sua finalidade, as pequenas (que ocupam poucos disquetes) são usadas para recuperação de sistemas danificados ou em monitoramento de redes de computadores.

De entre as maiores, distribuídas em CDs, podem-se citar: Slackware, Debian, Suse, e Conectiva. O que faz a diferença é como estão organizadas e pré-configuradas as aplicações. A distribuição Conectiva Linux, por exemplo, tinha as suas aplicações traduzidas em português, o que facilitou que usuários que falam a Língua Portuguesa tenham aderido melhor a esta distribuição. Hoje esta distribuição foi incorporada à Mandrake, o que resultou na Mandriva. Para o português, existe também a distribuição brasileira Kurumin, construída sobre Knoppix e Debian, e a Caixa Mágica, existente nas versões 32 bits, 64 bits, Live CD 32 bits e Live CD 64 bits, e com vários programas open source: OpenOffice.org, Mozilla Firefox, entre outros.

Existem distribuições com ferramentas para configuração que facilitam a administração do sistema. As principais diferenças entre as distribuições estão nos seus sistemas de pacotes, nas estruturas dos diretórios e na sua biblioteca básica. Por mais que a estrutura dos diretórios siga o mesmo padrão, o FSSTND é um padrão muito relaxado, principalmente em arquivos onde as configurações são diferentes entre as distribuições. Então normalmente todos seguem o padrão FHS (File Hierarchy System), que é o padrão mais novo.

Quanto à biblioteca, é usada a Biblioteca libc, contendo funções básicas para o sistema Operacional Linux. O problema está quando do lançamento de uma nova versão da Biblioteca libc, algumas das distribuições colocam logo a nova versão, enquanto outras aguardam um pouco. Por isso, alguns programas funcionam numa distribuição e noutras não. Existe um movimento LSB (Linux Standard Base) que proporciona uma maior padronização. Auxilia principalmente vendedores de software que não liberam para distribuição do código fonte, sem tirar características das distribuições. O sistemas de pacotes não é padronizado.

Caixa Mágica, Debian, Dual OS, Fedora, Freedows, Kurumin, Mandriva, Satux, Slackware, SuSE e Ubuntu são algumas das distribuições mais utilizadas actualmente, listadas aqui por ordem alfabética.

Um exemplo de distribuição que corre num CD é o Kurumin Linux, criado por Carlos E. Morimoto, baseada no Knoppix.

De entre as distribuições consideradas mais difíceis de gerir (por preferirem assegurar a estabilidade tecnológica em detrimento da interface de utilizador), destacam-se a Debian, Gentoo e Slackware.

Distribuições de propósito geral

Alguns grupos compilam distribuições Linux para propósitos especiais como firewalls, etc.

Distribuições Live CD

Estas distribuições correm (rodam) directamente do CDROM, sem necessidade de instalação.

Distribuições de propósitos especiais

Referências

Fonte: professorhugo.com.br

Enviado em Linux | Deixar um comentário »

Shorewall, uma excelente opção para firewall Linux

Publicado por Daniel Carraro Tomasini em Novembro 4, 2008

Este artigo é direcionado àqueles que desejam implementar o Shorewall como interface de configuração de regras de Iptables. O Shoreline, mais conhecido como Shorewall, possibilita uma configuração mais organizada e rápida do seu firewall. O servidor utilizado neste artigo é um Debian Etch 4.

Vamos ao que interessa!

Instalar os pacotes

# apt-get install shorewall shorewall-doc

Copiar os arquivos de exemplo para o diretório de configuração do shorewall

# cp /usr/share/doc/shorewall/examples/two-interfaces/* /etc/shorewall/.

Uma rápida explicação de cada arquivo de configuração, para uma implementação simples de firewall.

Zones

Neste arquivo é definido os tipos de zonas de sua rede. Os três tipos de zonas mais utilizados são:

loc – Define a zona local. Será utilizado para definir regras para a rede local.

net – Define a zona de Internet. Será utilizado para definir regras para o link de dados.

dmz – Define a zona delimitada.

A variável FW já é uma zona declarada implicitamente. Essa zona corresponde-se ao firewall e é utilizado para definir regras para o mesmo.

Editar o arquivo /etc/shorewall/zones e inserir a seguinte configuração:

################################################################
#ZONE TYPE OPTIONS IN OUT
################################################################
net ipv4
loc ipv4

# NUNCA REMOVER ESTA LINHA

Obs.: A zona FW não precisa ser definida, pois como já disse é implicitamente definida.

Interfaces

Neste arquivo são atribuídas zonas às interfaces de rede. Antes de tudo deverá existir uma estrutura de rede. Neste artigo estou utilizando eth0 para Internet (DHCP) e eth1 para rede local (IP STATIC).

Editar o arquivo /etc/shorewall/interfaces e inserir:

#########################################################
#ZONE INTERFACE BROADCAST OPTIONS
#########################################################
net eth0 detect dhcp,tcpflags
loc eth1 detect tcpflags,detectnets,nosmurfs

# NUNCA REMOVA ESTA LINHA

Masq

Mais conhecido como masquerade (mascaramento de rede) o masq define as máscaras de rede e ordem que elas serão apresentadas. Usado por servidores que servem como gateway para rede local.

Editar o arquivo /etc/shorewall/masq e inserir:

##################################################################
#INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC
##################################################################
eth0 eth1

# NUNCA REMOVER ESTA LINHA

Policy

Toda política da rede é definida nesta zona. Antes de executar qualquer regra de excessão definida na zona rules (próximo tópico), o Shorewall utiliza as regras globais definidas nesta zona para só então dar prosseguimento às excessões.

Editar o arquivo /etc/shorewall/policy e inserir:

#
# Policies for traffic originating from the firewall ($FW)
#
# If you want open access to the Internet from your firewall, change the
# $FW to net policy to ACCEPT and remove the ‘info’ LOG LEVEL.
# This may be useful if you run a proxy server on the firewall.
$FW net ACCEPT # LINHA 1
$FW loc ACCEPT # LINHA 2
$FW all REJECT info # LINHA 3

# Policies for traffic originating from the local LAN (loc)
#
# If you want to force clients to access the Internet via a proxy server
# on your firewall, change the loc to net policy to REJECT info.
loc net REJECT info
loc $FW REJECT info
loc ipsec ACCEPT
loc all DROP info

#
# Policies for traffic originating from the Internet zone (net)
#
net $FW DROP info
net loc DROP info
net all DROP info

# THE FOLLOWING POLICY MUST BE LAST
all all REJECT info

# ULTIMA LINHA – NUNCA REMOVA

Uma breve explicação de algumas linhas do conf policy:

LINHA 1 – Todas as requisições do firewall para a internet serão aceitas.
LINHA 2 – Todas as requisições do firewall para a rede local serão aceitas.
LINHA 3 – Todas as requisições do firewall para todos os outros lugares serão rejeitados e devidamente catalogado em log. Por isso o “info” ao final da linha.

As opções de ações usadas nas zonas policy e rules são:

ACCEPT – Aceita pacotes/requisições
REJECT – Rejeita pacotes/requisições e retorna mensagem de rejeição
DROP – Elimina pacotes/requisições e não retorna mensagem alguma

Rules

Nesta zona são definidas as regras finais para o destino e origem de cada pacote/requisição. Após terem passados pelas regras da zona policy, o firewall trata os pacotes com essas excessões e direciona-os para o seu destino/origem finais.

Editar o arquivo /etc/shorewall/rules e inserir:

##################################################################
#ACAO ORIGEM DESTINO PROTO DESTINO ORIGEM
#SOLICITANTE TAXA USUARIO
# ZONA ZONA PORTA PORTA(S)
##################################################################

# Aceita conexoes DNS vindas do firewall para a rede
#
DNS/ACCEPT $FW net

# Permite Ping vindos da “zone loc” para rede
#
Ping/ACCEPT loc $FW
Ping/ACCEPT loc loc

# Rejeita ping vindo da “zone net” batizados como “maus”…
#
Ping/ACCEPT net:200.200.200.00 $FW
Ping/DROP net $FW

ACCEPT $FW loc icmp
ACCEPT $FW net icmp

# Abrindo portas
#
ACCEPT net $FW tcp 22 # SSH
ACCEPT net $FW tcp 9000 # SSH
ACCEPT net $FW tcp 8080 # Tomcat6
ACCEPT net $FW tcp 9100 # Apache2
ACCEPT net $FW tcp 80 # Apache2
ACCEPT net $FW tcp 1521 # Oracle_Listener
ACCEPT net $FW tcp 10000 # Webmin
ACCEPT net $FW tcp 1158 # OEM

# Redirecionando conexões
# Neste exemplo estou direcionando uma requisição vinda da internet
# e direcionando-a para a rede local no IP 192.168.27.2 na porta 4899
#
DNAT $FW loc:192.168.27.2:4899 tcp 1158

# ULTIMA LINHA – NUNCA REMOVA

Esta foi uma breve explicação de como utilizar o Shorewall como firewall. Para quem deseja aprofundar-se neste software e implementar as outras diversas funcionalidades dele, o site oficial é http://www.shorewall.net

Fonte: andradeti.blogspot.com

Enviado em Linux, Segurança, Tecnico | Deixar um comentário »

Ubuntu Perfeito, agora em formato de script

Publicado por Daniel Carraro Tomasini em Outubro 16, 2008

O objetivo desse script é executa-lo uma única vez e deixar o Ubuntu pronto para uso segundo minhas próprias definições.

Ele segue a cartilha do artigo “Ubuntu Perfeito – versão 8.04″ e contém muitas novas adições. Eu tentei dar o esmero em vários pontos do script, por exemplo, alguns pacotes eu testo para saber se eles estão dentro do repositório e se não estiverem então faço o download diretamente dos arquivos .deb. Também é verificado se o pacote já não se encontra instalado antes de iniciar um download enorme. Muitas etapas como o suporte a mapeamento à unidades de rede requer que usuarios estejam dentro do grupo [fuse] e o script faz isso, idem para o VirtualBox [vboxusers] e programas que exibam o nivel de tinta de impressoras [lp].

Ele ainda não está terminado, mas estou disponibilizando para testes.
Não há nada de nocivo no script, ele é um monte de IFs, APT, WGET e só foi testado no Ubuntu Intrepid(8.10) e Ubuntu Hardy (8.04), mas suspeito que funcione em todas as distros baseadas em Debian.

Apesar de ter sido escrito em bash-script, ele faz pleno uso do utilitário chamado zenity que responsável por dar uma camada de interface gráfica ao dialogar com o usuário usando checkboxes, checklist, warnings e afins.

Baixe o script ubuntu-perfeito-20081010 e depois executar no terminal :

cd /local/onde/descarreguei/o/script
mv ubuntu-perfeito-[data].odt ubuntu-perfeito.sh
chmod a+x ubuntu-perfeito.sh
sudo ./ubuntu-perfeito.sh

Se você não é fã de uso do terminal, apenas renomeie o arquivo pelo próprio nautilus e clique em propriedades de arquivo e então ajuste a permissão para execução como é exibido na figura abaixo :

Depois disso, ainda com o nautilus aberto onde o script foi descarregado, basta clicar com o botão direito sobre o arquivo e escolher “Abrir com outra aplicação” como é mostrado na figura a seguir :

Depois escolha “Executar um comando personalizado” e digite “gksu bash” como é exibido na figura :

Lhe será solicitado a senha de administrador que você deverá fornecer :

Daí em diante, o script será executado normalmente e basta orientar-se pelas instruções na tela :

A relação de tarefas incluídas neste script são :
Acrescentando repositorio remastersys
Acrescentando repositorio Sun Microsystem VirtualBox
Acrescentando o repositorio WINE
Acrescentando o repositorio Google
Acrescentando o repositorio multimedia Medibuntu
Acrescentando repositório para KDE 4.1 atualizado
Acrescentando repositorio PPA for Clamav Update Team
Acrescentando o repositório PPA para o instalador do Ubuntu Games
Acrescentando o repositório Playdeb
Acrescentando o repositorio para o Skype
Acrescentando repositorio PPA para atualizacoes do compiz
Instalação e remoção de idiomas
Atualizando tabela de hardwares detectaveis
Instalando dependencias de compilação de módulos e programação
Componentes extras para o Firefox
Instalação do plugin flash shockwave versao 9 ou 10 para firefox
Instalando compiz e seus componentes auxiliares
Instalando temas para o OpenOffice
Instalando o parcellite
Instalando o parcellite no inicio de sessão dos usuarios do Ubuntu Intrepid
Instalando visualizadores de medidor de tinta para impressoras jatos de tinta e acrescentando usuarios selecionados no grupo [lp]
Instalando biscoito da sorte e modificando /etc/bash.bashrc para exibi-los
Instalando todos compactadores/descompacotadores de formatos populares
Instalando o remastersys
Instalando o unetbootin, que em complemento ao remastersys para gerar um LiveUSB
Instalando o Acrobat Reader 8.1.2 em português
Instalando o plugin para Acrobat chamado FileOpenPDF responsavel por visualizar PDFs protegidos por DRM
Instalando MS-CoreFonts
Instalando fontes truetype Liberation
Instalando muitas outras fontes
Instalando pacotes comum para multimedia
Instalando Codecs para o backend gstreammer 0.10
Instalando Codecs proprietários para mswindows (w32codecs)
Instalando o tocador multiformatos VLC
Instalando o tocador multiformatos MPlayer
Instalando o tocador multiformatos XINE
Estabilizando o XINE como backend preferido do TOTEM em detrimento do gstreammer(padrao original)
Instalando plugins para o TOTEM
Instalando o powertotem que acrescenta funcionalidades extras ao TOTEM
Determinando o backend responsável para tocar formatos multimedia no navegador
Instalando dvdcss e desativando de DRMs que bloqueiam players de DVDs
Instalando utilitarios de composição de dvd/videos/legendas
Instalando Sun-Java, o mais compativel de todos os javas
Instalando backends para uso de mapeamento de unidades de rede
Instalando frontend gráfico para cliente de FTP
Instalando cliente de bittorrent
Instalando o frostwire
Determinando se haverá icones auxiliares na área de trabalho
Instalando o cairo-dock e cairo-dock-plugins
Instalando o VirtualBox
Instalação de usuarios selecionados no grupo [vboxusers]
Verifica e recompila se necessario o modulo do virtualbox
Instalando o GoogleEarth
Corrigindo nome de pastas do GNOME- renomeação das pastas especiais em $HOME integrado ao GNOME, por exemplo, “Área de Trabalho” fica simplesmente “desktop”, “Música” fica “musica”, etc… sem acentos e minusculas. Esse ajuste pode valer para apenas um usuário ou todos.

Tem outras coisas que penso em adicionar e que já estão prontas como :

“r5u870″ “webcam ID 05ca:1870 (r5u870) usado no HP-Pavillion”
“microdia” “webcam ID 0c45:624f Microdia”
“syntek” “Webcam Syntek Semicon DC-1125″
“smartlink” “Smartlink e winmodens compativeis”
“modem_agere” “Winmodem Agere V92″

Mas que estou receoso de solta-los agora, porque módulos são muito mais complicados do que programas e requer mais tempo de testes.

Fonte: hamacker.wordpress.com

Enviado em Linux, Utilidades | 1 Comentário »

Aplicativos em modo texto

Publicado por Daniel Carraro Tomasini em Outubro 13, 2008

Nem só de cat e ls vive o terminal. Por estranho que possa parecer, existem diversos aplicativos elaborados para o modo texto, que cobrem quase todas as principais áreas. Você poderia questionar a utilidade destes aplicativos, já que, afinal, existem aplicativos gráficos muito mais elaborados. Apesar disso, os aplicativos em modo texto conservam algumas vantagens importantes. Eles são mais leves, o que permite que sejam usados até mesmo em máquinas muito antigas, podem ser usados remotamente (via SSH ou outros meios) mesmo através de conexões lentas e podem também serem usados dentro de shell scripts, onde é possível combinar o trabalho de diversos comandos para realizar tarefas complexas.

Um gerenciador de arquivos completo como o mc consome apenas 2 MB de memória RAM, enquanto o centericq (cliente ICQ, AIM, etc.) consome pouco mais de 500 KB. Graças ao GPM, é possível utilizar o mouse na maior parte dos aplicativos de modo texto e muitos são baseados na biblioteca ncurses, o que permite incluir janelas, menus, etc., o que torna seu uso muito similar ao dos programas gráficos. Ao contrário da crença popular, pouca gente ainda roda aplicativos em terminais de texto puro, quase sempre eles são utilizados dentro de um terminal gráfico, lado a lado com outros aplicativos.

Vamos a alguns exemplos:

Navegadores: Entre os navegadores em modo texto, as atenções se dividem entre o Links e o Lynx, que apesar do nove parecido, são dois softwares bastante diferentes. Além de serem uma opção para casos em que você precise pesquisar alguma coisa em uma máquina onde o ambiente gráfico não está funcionando, eles servem também como opções de navegadores leves, que você pode usar em situações diversas. Por não carregarem imagens, arquivos em Flash ou perfumarias diversas, eles são uma opção para momentos em que a conexão está lenta. Para usá-los, basta chamá-los no terminal, seguido pela página desejada, como em:

$ links gdhpress.com.br

ou

$ lynx guiadohardware.net

A grande diferença entre os dois é que o Lynx reformata as páginas em uma única coluna (assim como fazem muitos navegadores para celular), enquanto o Links se esforça para manter a formatação original. De uma forma geral, o Lynx se sai melhor quando você está em um terminal de texto puro, com uma resolução de tela baixa e sem mouse, enquanto o Links é mais agradável de usar quando você está usando o navegador dentro de um terminal gráfico. Apesar de rodar no terminal, o Links suporta o uso do mouse, de forma que você pode navegar clicando nos links, como faria em qualquer navegador gráfico:

O Lynx oferece a vantagem de incluir um melhor suporte a Javascript, permitindo acessar um volume muito maior de páginas que exigem login ou usam recursos mais específicos. Ele é também capaz de utilizar as cores para diferenciar os elementos do texto, enquanto o Links é basicamente monocromático.

No Links, pressione F10 para abrir o menu de funções. Para que ele exiba os caracteres acentuados, mude o charset para “ISO 8859-1″ no “Setup > Character Set”. No mesmo menu está disponível também a opção de mudar a linguagem para Português do Brasil.

Em ambos, você pode usar as setas para a esquerda e direita para voltar e avançar e a tecla “q” para sair. Para abrir uma nova página, pressione a tecla “g”; para rolar a página use “Page Up” e “Page Down” e, para navegar entre os links, use os direcionais para cima e para baixo ou a tecla Tab.

Algo que pouca gente sabe é que o links pode ser utilizado também como um navegador gráfico (mesmo em um terminal de texto puro), tirando proveito do uso do frame-buffer. Para isto, basta chama-lo com o comando “links -g”.

Na maioria das distribuições, o pacote é compilado sem suporte a gráficos, por isso a opção não funciona (seria necessário baixar o código fonte e recompilar usando a opção “–enable-graphics” ao rodar o ./configure), mas no caso do Slackware é necessário apenas que o frame-buffer esteja ativado.

Outra dica, desta vez sobre o lynx é que ele pode ser usado como uma forma simples de converter páginas Web para arquivos de texto, que podem ser lidos no seu smartphone ou mp3player ou transportadas mais facilmente. Para isso, use o comando:

$ lynx -dump gdhpress.com.br > gdh.txt

Isto salvará a página index do site no arquivo texto.txt. Basta substituir o link pelo da página desejada. O arquivo de texto fica com a mesma formatação que você veria ao visualizá-lo em um terminal com o lynx. Os links no meio do texto são substituídos por números de referência ([01], [02], etc.) e as url’s aparecem no final do texto. Esse tipo de flexibilidade faz com que o lynx seja muito usado em shell scripts, sempre que é necessário extrair alguma informação de uma página web.

Outra dica é que você pode visualizar arquivos de imagem no terminal usando o comando fbi, como em:

$ fbi imagem.jpg

Ele exibe a imagem no terminal usando o frame buffer, assim como ao usar o “links -g”. Para voltar ao terminal, pressione Esc.

Download de arquivos: O wget é um gerenciador de downloads bastante competente, que oferece um grande volume de opções, todas usadas via linha de comando. Isso faz com que ele seja uma opção muito prática para download de arquivos em geral, já que você pode copiar a URL

O uso mais básico é usar o wget seguido da opção “-c”, que faz com que ele continue o download caso interrompido, como em:

$ wget -c link

Se precisar interromper o download, pressione Ctrl+C para parar e em seguida use o histórico (seta para cima) para executar novamente o comando e continuar de onde parou. Caso o arquivo já esteja completo, ele exibe um aviso e não faz nada.

Se você precisar baixar vários arquivos em sequência, como em casos em que você precisa baixar os vários CDs de uma distribuição, use o ponto e vírgula para separar vários comandos do wget, como em:

$ wget -c url1; wget -c url2; wget -c url3; wget -c url4

Isso faz com que os 4 arquivos sejam baixados em sequência, um de cada vez. Se quiser falar difícil, você pode fazer a mesma coisa usando:

$ for i in url1 url2 url3 url4; do wget -c $i; done

Este é na verdade um mini shell script, que faz com que ele execute o comando “wget -c” para cada uma das urls especificadas, armazenando o valor de cada uma na variável “$i”. Esta é uma função simples, que é muito usada em situações que você precisa rodar o mesmo comando repetidamente.

Continuando, caso a conexão esteja ruim e a transferência esteja parando freqüentemente, você pode especificar um timeout usando a opção “-T”, ela faz com que o wget reinicie a transferência caso não receba dados dentro do tempo especificando (em segundos), repetindo o processo até conseguir baixar o arquivo, como em:

$ wget -c -T 30 link

Uma dica é que você pode selecionar a URL do arquivo a ser baixado na janela do navegador e colar o texto no terminal usando o botão central do mouse. Se você estiver usando o konsole ou o gnome-terminal, você pode também colar o texto da área de transferência clicando com o botão direito sobre o terminal e usando a opção “colar”.

Mensagem: Por estranho que possa parecer, você pode usar o MSN, ICQ e até mesmo o Gtalk (que na verdade utiliza o protocolo Jabber) em modo texto, graças ao CenterICQ, disponível no: http://thekonst.net/centericq/

Embora a interface não seja exatamente simples de usar, ele é surpreendentemente completo do ponto de vista dos protocolos suportados, oferecendo suporte a todas as principais redes. Você encontra o pacote para o Slackware no http://www.slacky.eu.

Outro exemplo de cliente multiprotocolo é o Pebrot, disponível no: http://pebrot.sourceforge.net/. A interface é muito mais simples, mas ele oferece como ponto forte a possibilidade de ser controlado através de comandos, o que permite usá-lo dentro de shell scripts. Com isso, você pode criar bots simples para monitorar o status dos contatos, mandar mensagens automáticas e assim por diante.

MP3 e CD: O utilitário mais simples para tocar arquivos de áudio via terminal é o mpg123, que pode ser chamado diretamente no terminal, seguido do nome do arquivo a tocar, como em:

$ mpg123 arquivo.mp3

Você também pode tocar uma playlist através do comando “mpg123 -@ arquivo”. A playlist pode ser gerada através de vários programas tocadores de mp3. No XMMS, por exemplo, você precisa apenas clicar com o botão direito sobre a janela do editor de playlists e em “salvar lista” para gerar a playlist da lista de faixas atual. Se por acaso o comando não estiver disponível, procure pelo pacote “mpg123″.

Uma opção mais elaborada é o Orpheus (do mesmo criador do CenterICQ) que pode ser baixado no http://konst.org.ua/orpheus. Ele é capaz de tocar tanto MP3 quanto CDs de áudio e oferece uma interface pseudo-gráfica, baseada no ncurses, com menus e tudo mais.

Gerenciamento de arquivos: Em termos de gerenciamento de arquivos, o mc é sem dúvidas a melhor opção. Ele é também baseado no ncurses e suporta o uso do mouse. A interface é baseada em teclas de atalho e é um pouco complicada de usar no início, mas o volume de opções disponíveis permite executar muitas operações que não são possíveis ou não são práticas mesmo em gerenciadores gráficos, como o Konqueror e o Nautilus. Essa combinação de funções e leveza faz com que ele ainda seja bastante utilizado:

O mcedit (o editor de textos) surgiu originalmente como um módulo do mc, destinado a visualizar aquivos de texto, mas eventualmente acabou ganhando vida própria, passando a ser usado separadamente. De qualquer forma, os dois continuam ligados: para instalar o mcedit, você precisa instalar o pacote “mc”, que inclui também o gerenciador de arquivos.

Screenshots: Você pode tirar screenshots via linha de comando usando o import, utilitário incluído na maioria das distribuições. Naturalmente ele se aplica apenas quando você estiver usando um terminal dentro do modo gráfico. A sintaxe básica é:

$ import tela.png

Ao executar o comando, o botão do mouse virará um cursor. Desenhe um retângulo na parte da tela que você deseja capturar e ela será automaticamente capturada e salva no arquivo “tela.png” no diretório corrente. Se você preferir capturar o conteúdo de uma janela, basta clicar sobre a barra de título. Se por outro lado você quiser um screenshot da tela toda, não apenas de uma janela, adicione a opção “-windows root”, como em:

$ import -window root tela.png

O formato de compressão das imagens é especificado diretamente no nome do arquivo. Nos exemplos salvei as imagens em .png, mas para salvá-las em .jpg basta alterar a extensão do arquivo gerado, “import imagem.jpg” por exemplo.

A principal vantagem do import é que ele pode ser chamado a partir de scripts. Você pode por exemplo agendar um trabalho no cron para tirar um screenshot a cada minuto por exemplo e assim poder monitorar o que está sendo feito no PC.

Bittorrent: Você pode baixar arquivos via bittorrent em modo texto usando o btdownloadcurses e o btlaunchmanycurses, que são destinados a, respectivamente, baixar apenas um arquivo e baixar diversos arquivos .torrent dentro de uma pasta. A sintaxe para especificar opções adicionais é um pouco complicada e você vai sentir falta de algumas funções especiais disponíveis nos clientes gráficos mais elaborados, como a possibilidade de encriptar a transmissão, mas eles atendem bem à função básica, que é baixar os arquivos. Ambos fazem parte do pacote “bittornado”, que no Slackware está disponível dentro da pasta “/extra/bittornado”.

O uso básico é usar o btdownloadcurses seguido pelo arquivo a ser baixado, como em:

$ btdownloadcurses openSUSE-11.0-DVD-i386.torrent

Como de praxe, você não precisa necessariamente digitar o nome do arquivo, pode usar um “ls” e em seguida copiar e colar usando o botão central do mouse, ou simplesmente usar a tecla TAB para completar o nome do arquivo. Caso precise baixar arquivos com caracteres especiais, coloque o nome entre aspas simples (’), isso faz com que o shell deixe de interpretar os caracteres especiais. Para encerrar o download, pressione Ctrl+C.

Caso precise baixar vários arquivos de uma vez, coloque todos dentro de uma pasta e, dentro dela, use:

$ btlaunchmanycurses ./

Ele monitora o conteúdo da pasta, ativando novos arquivos que forem copiados para dentro dela e desativando o compartilhamento de arquivos removidos. Isso permite que você deixe um terminal aberto, rodando o btlaunchmanycurses e vá simplesmente copiando novos arquivos .torrent que quiser baixar para dentro delas, sem precisar fechar e abrir novamente o btlaunchmanycurses para cada alteração.

Para limitar a taxa de upload, adicione a opção “–max_upload_rate”, seguida pela taxa máxima desejada (em kbytes), como em:

$ btdownloadcurses –max_upload_rate 32 openSUSE-11.0-DVD-i386.torrent

ou:

$ btlaunchmanycurses ./ –max_upload_rate 16

Como pode ver, no caso do btdownloadcurses, o parâmetro vem antes do nome do arquivo e no caso do btlaunchmanycurses vem depois. O bittornado é uma versão aprimorada dos clientes bittorrent originais, que fazem parte do pacote “bittorrent”. O pacote inclui também outros utilitários relacionados, como o “bt-t-make” (usado para criar torrents) e o “bttrack” (que permite compartilhá-los, usando seu PC como tracker), além do “btdownloadgui”, que é um cliente gráfico.

Vídeo: O Mplayer é um dos players de mídia mais usados no Linux. Existem diversas interfaces para ele, tais como o Gmplayer e o Kmplayer, mas na verdade o Mplayer pode ser usado diretamente via linha de comando, basta usar o comando “mplayer”, seguido do arquivo a exibir, como em:

$ mplayer video.avi

Para exibir um DVD (para assistir DVDs protegidos, é necessário que o pacote libdvdcss esteja instalado), o comando básico é:

$ mplayer dvd://1

A página de manual do mplayer (man mplayer) inclui um volume absurdo de parâmetros e opções que podem ser adicionados. Para assistir o DVD com o áudio em Inglês e as legendas em Português, abrindo o filme diretamente, sem passar pelo menu inicial, o comando seria:

$ mplayer dvd://1 -alang en -slang pt

Originalmente, executar estes comandos faz com que ele abra uma nova janela e passe a exibir o filme, como qualquer outro aplicativo gráfico. A linha de comando no caso serve apenas para controlar o aplicativo.

A parte engraçada começa quando você começa a brincar com as opções de saída do Mplayer, que permitem que ele seja usado mesmo em um terminal de texto puro. Algumas mini-distribuições, como, por exemplo, o emovix, utilizam estas opções para exibirem vídeos mesmo sem ter o X instalado. Alguns exemplos de comandos para assistir aos vídeos a partir do modo texto são:

$ mplayer -vo svga filme.avi

Este comando usa o driver SVGA, que funciona na maioria das placas, exibindo o filme em tela cheia. Para usá-lo, é necessário que os módulos “svgalib” e “svgalib_helper” estejam carregados. Caso o mplayer reclame que não consegue abrir o device “/dev/svga”, experimente carregá-los usando o comando “modprobe”.

$ mplayer -vo vesa filme.avi

Este segundo comando usa o driver VESA, que funciona em algumas placas que não são compatíveis com o driver SVGA.

$ mplayer -vo fbdev filme.avi

Esta terceira opção é baseada no uso do frame-buffer, o mesmo recurso que é usado para exibir imagens no terminal. O uso de processamento é maior que no VESA e no SVGA, mas isso não é problema para as máquinas atuais. A principal dica é que para usar a opção “-vo fbdev”, o lilo ou grub deve ter sido configurado para usar 16 bits de cor (os valores “785″, “788″ ou “791″). O Slackware usa 256 bits por padrão, o que faz com que o Mplayer exiba um erro e aborte a exibição.

$ mplayer -vo aa filme.avi

Se você estava achando estranho assistir vídeos diretamente no terminal, se prepare para o driver mais curioso. A opção “-vo aa” faz com que o vídeo seja exibido usando caracteres de texto, transformando o vídeo em uma espécie de ASCII art anabolizado. Ela na verdade não tem muito uso prático, já que a qualidade é muito ruim, mas não deixa de ser um truque interessante:

Fonte: www.gdhpress.com.br

Enviado em Linux, Tecnico | Deixar um comentário »

Entendendo Ameaças Ocultas: Rootkits e Botnets

Publicado por Daniel Carraro Tomasini em Outubro 8, 2008

O US-CERT publicou uma artigo, entitulado “Cyber Security Tip ST06-001 – Understanding Hidden Threats: Rootkits and Botnets”, muito importante para internautas e profissionais ligados a tecnologia da informação, que busca melhor orientar usuários de computadores e da Internet quanto aos efeitos e as boas práticas no combate e prevenção de Rootkits e Botnets.

Por Mindi McDowell, Tradução Julio Dutra.

Atacantes continuam procurando por novos caminhos para acessar sistemas computadorizados. O uso de métodos ocultos como rootkits e botnets está aumentando, e Você pode ser uma vítima mesmo sem imaginar.

Um rootkit é um pequeno software/programa que pode ser instalado e ocultado em seu computador sem seu conhecimento. Ele pode ser imbutido em um pacote maior de software ou instalado em seu computador através de uma vulnerabilidade em seu computador, talvêz convencendo Você a baixá-lo e instalá-lo (engenharia social). Rootkits não são necessariamente maliciosos, mas podem ocultar atividades maliciosas. Atacantes podem estar roubando informações, monitorando suas ações, modificando programas, ou realizando ações em seu computador, tudo isso sem ser detectado.

Botnet é um termo derivado da idéia de redes de robôs. Em sua forma mais básica um bot é simplesmente um programa de computador autônomo, ou robô. No contexto de botnets, bots se referem a computadores que possam ser controlados por uma ou mais fontes externas. Um atacante usualmente ganha o controle infectando o computador com um vírus ou outro código malicioso que lhe dá acesso. Seu computador poderá fazer parte de uma rede de bots mas aparentemente parecerá normal. Botnets são utilizadas para uma gama bastante abrangente de atividades, do envio de spam e distribuição de vírus, à ataques de negação de serviço.

Botnets e Rootkits são considerados ameaças principalmente por serem ocultos. Apesar de Botnets não serem ocultos da mesma forma que Rootkits, são também indetectáveis. Se um Rootkit está instalado em seu computador, Você provavelmente não está a par disto, inclusive anti-vírus convencionais também não estão preparados para estas formas de código maliciosos. O que torna mais difícil a detecção destes programas é que eles ainda estão sendo criados para atualizar a sí próprios.

Atacantes podem utilizar Rootkits e Botnets para acessar e modificar informações pessoais, atacar outros computadores, e cometer outros crimes, todos enquanto estão indetectáveis. Utilizando múltiplos computadores, atacantes aumentam o impacto de seus crimes. Pelo fato de uma Botnet possuir diversos computadores executando o mesmo comando, um atacante pode ter cada bot escaneando múltiplos computadores por vulnerabilidades, monitorando atividade online, ou coletando informações digitadas em formulários online.

Não é difícil se precaver dessas ameaças. Se Você já pratica boas medidas de segurança reduz em muito o risco de ter seu computador comprometido:

* Utilize e mantenha um antivírus que reconheça e proteja o computar contra os vírus mais conhecidos, assim Você tem a chance de detectar e remover programas maliciosos antes de causar algum dano. Pelo fato de os criadores de vírus estarem continuamente criando novas versões de seus vírus, é importante manter a biblioteca do antivírus sempre atualizada. Algumas empresas fornecedoras de antivírus ainda disponibilizam ferramentas exclusivas ao combate de rootkits, vale conferir;

* Alguns Firewalls são capazes de prevenir alguns tipos de tráfego malicioso e bloquear infecções antes que entrem no computador, limitando também o tráfego enviado pelo seu computador, caso este já esteja comprometido. O sistema operacional Windows já possue Firewall. Certifique de estar habilitado e corretamente configurado;

* Selecione senhas que sejam difíceis de serem descobertas por atacantes, e utilize senhas diferentes para serviços e equipamentos diferentes. NUNCA escolha “salvar senha neste computador”.

* Instale patches corretivos, então atacantes não poderão tomar vantagem de problemas conhecidos ou vulnerabilidades. Muitos sistemas operacionais oferecem atualizações automáticas, se esta opção estiver disponível, habilite.

* Siga as boas práticas de segurança. Tome as precauções apropriadas quando utilizar e-mail e navegadores, para reduzir o risco de suas ações iniciarem uma infecção.

Se Você tiver um Rootkit em seu computador, ou um atacante estiver utilizando seu computador em uma Botnet, Você pode não saber. Mesmo se Você descobrir que é uma vítima, é muito difícil para a maioria. O atacante pode modificar arquivos em seu computador, e a simples remoção do programa malicioso pode não remover o rootkit por completo, e não resolverá o problema. Se Você suspeita ser uma vítima, procure ajuda com um profissional.

Uma alternativa é utilizar software desenvolvidos por fabricantes de antivírus específicos para remover Rootkits. Se isto não resolver, Você vai precisar formatar e reinstalar o sistema operacional. Só uma formatação pode remover todos os arquivos do sistema, inclusive os infectados. Portanto, não basta fazer uma recuperação do sistema através de “Discos de Recuperação”.

Link para o artigo original.

Enviado em Linux, Segurança, Tecnico | Deixar um comentário »

Fedora, Red Hat e a segurança nas distribuições Linux

Publicado por Daniel Carraro Tomasini em Setembro 10, 2008

No dia 22 de agosto, o Projeto Fedora emitiu um “relatório de infra-estrutura” confirmando o que muitos observadores já suspeitavam: houve uma grave falha de segurança no projeto. O atacante conseguiu chegar ao sistema usado para assinar os pacotes distribuídos pelo Fedora. É claro que isso está bem perto de ser o pior dos cenários: se um intruso se apodera de um sistema desses, capturar a chave de assinatura dos pacotes e a passphrase usada para empregar a chave torna-se uma tarefa relativamente simples. E essas assinaturas, por sua vez, poderiam ser usadas para criar pacotes hostis que seriam aceitos como genuínos por instalações do Fedora de todo o mundo.

Felizmente para o projeto Fedora (e para seus usuários), uma auditoria determinou que ninguém usou a chave durante a permanência do intruso. Por isso, ainda que houvesse a possibilidade da passphrase ter sido capturada, ela não foi exposta e, conseqüentemente, não foi comprometida.

Nem é preciso dizer que mesmo assim o projeto está mudando sua chave de assinatura de pacotes.

O interessante é que o Fedora não foi o único alvo do ataque: o Red Hat também foi comprometido. Ao contrário do Projeto Fedora, a Red Hat não emitiu um comunicado específico sobre a invasão; ao invés disso, a informação foi incluída em uma atualização de segurança do openssh. Nesse caso o atacante teve mais sucesso, ao ponto de conseguir assinar “…um pequeno número de pacotes OpenSSH relativos apenas ao Red Hat Enterprise Linux 4 (apenas nas arquiteturas i386 e x86_64) e no Red Hat Enterprise Linux 5 (apenas na arquitetura x86_64).” Vale a pena questionar esse jogo de palavras: só é preciso assinar um único pacote openssh (o que certamente é um “pequeno número de pacotes”) para comprometer milhares de hosts com o RHEL, e os “apenas” que eles usam se referem ao que deve ser a maioria dos sistemas RHEL instalados. É para assustar mesmo, mas a Red Hat já se convenceu de que nenhum dos pacotes comprometidos foram entregues aos assinantes do RHEL. Logo, esse ataque também falhou — mas foi por pouco.

Nem é preciso dizer que explicações como essa trazem mais perguntas do que respostas. A pergunta que o Fedora e a Red Hat vão ter que responder mais cedo ou mais tarde é: como esse invasor entrou? Presume-se que o Fedora e a Red Hat rodem suas próprias distribuições, cada qual em seu sistema interno; deduz-se que, se essas distribuições contêm uma vulnerabilidade que permitiu a um atacante entrar no sistema, muitos outros grandes sistemas também podem estar vulneráveis. Se ao invés disso, o comprometimento do sistema for resultado de um erro de um administrador ou desenvolvedor (ou, quem sabe, de um laptop perdido), os administradores responsáveis por sistemas Fedora e RHEL podem dormir um pouco mais tranqüilos. De qualquer maneira, eles merecem saber como esses eventos se passaram.

Algumas pessoas gostariam de dispor dessa informação imediatamente. Além disso, imagina-se que haja uma boa quantidade de reclamações (também, imagina-se, de um grupo relativamente pequeno de pessoas) nas listas do Fedora quanto à maneira como o incidente foi tratado. Este editor também argumentou que as informações levaram muito tempo para vir à tona. Agora vou argumentar que, embora o Fedora ainda precise revelar algumas coisas, o projeto declarou o suficiente para conseguir respirar um pouco enquanto tenta recompor sua infra-estrutura e entender o que de fato aconteceu. Há vários bons motivos para que essas informações não tenham sido divulgadas imediatamente, incluindo a óbvia possibilidade de que ninguém saiba ainda como o invasor conseguiu acesso ao sistema. Não adianta malhar o Fedora nesse momento.

De qualquer maneira, qualquer coisa que o projeto possa dizer aos seus usuários sobre se há ou não motivos para que eles se preocupem com uma vulnerabilidade não revelada em seus sistemas seria bem-vinda, e quanto mais cedo isso acontecer, melhor.

Enquanto isso, o que pode ser feito, e o que o membro do conselho do Fedora, Jeff Spaleta, em particular, tem defendido, é que se pense em como lidar com a situação da próxima vez. Segundo Jeff,

    Temos um problema de comunicação? Talvez. Mas problemas de comunicação não equivalem a problemas de confiança. Mas considerando que foi o primeiro evento dessa natureza a atingir o projeto, não acho de todo inesperado que tenham havido problemas de comunicação. Não acho que nenhum de nós, da Red Hat ou de fora dela, já tenha debatido sobre como lidar com esse tipo de situação. Não me lembro de ter havido algum debate público sério sobre como deva se dar a comunicação em uma situação dessas. E não vou aceitar que as pessoas pensem que fazer as coisas de um modo diferente deveria ser algo óbvio para aqueles em posição de lidar com as informações.

    Se as pessoas querem que as coisas melhorem, se (Deus me livre) uma coisa dessas acontecer novamente, então é preciso trabalhar sério para que seja redigido um processo de comunicação aceito legalmente como um processo de trabalho viável, sem tocar perigosamente em questões de responsabilidade legal.

O Projeto Fedora certamente deve preparar uma política específica para situações como essa. Seria bom para os usuários do Fedora, mas seus efeitos poderiam ir além disso: uma política desse tipo poderia servir de exemplo para outros distribuidores. Afinal de contas, é provavelmente seguro dizer que o Fedora não é o único distribuidor que ainda não se encarregou de elaborar planos para esse tipo de desastre.

Todos nós precisamos de planos como esse. Seja isso bom ou ruim, os distribuidores hoje ocupam uma posição importante no que se refere à segurança de boa parte da internet. Milhões de sistemas rodam pacotes assinados por distribuidores Linux; eles dependem, implicitamente, da segurança do processo usado na criação dos pacotes. Esse processo não é pequeno; ele pode envolver centenas de desenvolvedores, sem contar todos os envolvidos nos projetos de desenvolvimento upstream. As conseqüências de uma falha em qualquer elo da corrente de confiança podem ser drásticas. Não é de se surpreender que o sistema da distribuição tenha sido atacado; talvez a única surpresa seja que isso não aconteça com mais freqüência (nós, pelo menos, nunca soubemos de nada a esse respeito). Ataques como esse vão acontecer novamente, e os desenvolvedores precisam ter uma idéia bem definida de como reagir.

Vale mencionar um assunto relacionado: no momento em que escrevo este artigo (25 de agosto), já se vão quase duas semanas sem atualizações de segurança no Fedora. Os usuários do Fedora ainda não receberam patches para várias vulnerabilidades significativas, como a vulnerabilidade do link simbólico do postfix. A Red Had agiu melhor, mas não muito. Os usuários do Linux dependem fortemente do processo de atualizações de segurança e, no caso dessas duas distribuições, o processo foi seriamente abalado. Se alguma vulnerabilidade realmente séria tivesse sido revelada nesse período, as pessoas encarregadas de manter seguros sistemas Fedora e Red Hat poderiam estar numa situação difícil. Não é preciso ser muito paranóico para para imaginar esse tipo de abalo sendo sendo usado intencionalmente como parte de um “zero-day attack”, em que um espertinho se aproveita de alguma vulnerabilidade que tenha sido anunciada antes que o fornecedor tenha tido tempo de emitir um patch.

Esse incidente serve como uma espécie de alarme tanto para os distribuidores quanto para os usuários. Os distribuidores que desejem manter a confiança de seus usuários devem pensar em documentar coisas como:

  • Como manter seguros os elos da corrente do empacotamento. Seria bom saber quantas pessoas podem assinar pacotes, e como elas obtêm acesso aos sistemas nos quais os pacotes são assinados.
  • Que tipo de planos o distribuidor tem para lidar com os problemas de segurança. É de se imaginar que a Red Hat tenha um bom número de funcionários trabalhando para entender o incidente e se recuperar dele. Será que outros distribuidores estariam dispostos e seriam capazes de fazer o mesmo?
  • Quais são os planos para lidar com falhas de segurança graves? Como distribuir atualizações de segurança quando a integridade do sistema de pacotes estiver comprometida?
  • Se algo der errado, quando e como as informações serão comunicadas à comunidade de um modo geral?

Qualquer um que esteja implantando um sistema importante baseado em Linux deve se fazer essas perguntas ao escolher uma distribuição para o sistema. Se o sistema exige alta confiabilidade, provavelmente faz sentido buscar um fornecedor que ofereça garantias mediante uma taxa. Mas a lição que aprendemos com os eventos recentes é a de que agora é a hora de fazermos essas perguntas, e não quando algo der errado e todo mundo estiver correndo em círculos.

De modo geral, os usuários do Linux têm sido muito bem servidos pelos distribuidores desde o início. Os distribuidores reúnem milhares de programas e os integram em um todo coerente; depois eles disponibilizam os resultado, muitas vezes de graça. Eles fornecem correções quando algo dá errado, e a maioria deles dá uma atenção especial aos problemas de segurança. Eles têm feito um trabalho de excelente qualidade, não sendo usados como veículos de programas hostis. É um ótimo sistema, e ele não mudou. Mas aprendemos alguma coisa sobre o quanto nós dependemos desse sistema, e sobre como ele pode falhar. Aplicar as lições aprendidas com esse episódio deve nos ajudar a ter mais segurança no futuro.

Fonte: Steven Goodwinlwn.net
Tradução por Roberto Bechtlufft

Enviado em Linux, Segurança | Deixar um comentário »

Introdução à Administração de Sistemas

Publicado por Daniel Carraro Tomasini em Agosto 1, 2008

Pesquisando por informações diversas por ai achei uma documentação muito boa da Red Hat para quem é aspirante a administrador de sistemas Linux.

O Introdução à Administração de Sistemas Red Hat Enterprise Linux contém informações introdutórias para novos administradores de sistemas Red Hat Enterprise Linux. Este manual não ensina a executar uma tarefa específica sob o Red Hat Enterprise Linux. Ao invés disso, traz o conhecimento acumulado ao longo dos anos por diversos administradores de sistemas experientes.

Este manual assume que você tem uma experiência limitada como usuário do Linux, mas nenhuma experiência como administrador de sistemas Linux. Se o Linux for completamente novo para você (e o Red Hat Enterprise Linux especificamente), deve começar adquirindo um livro introdutório sobre o Linux.

Leia mais…

Enviado em Carreira, Linux, Tecnico | 1 Comentário »

Gerenciando processos no Linux

Publicado por Daniel Carraro Tomasini em Julho 16, 2008

Introdução

A partir do momento em que inicializamos qualquer sistema Linux, temos processos rodando na memória. Basicamente tudo que um sistema operacional executa é um processo, se o servidor Apache está rodando, ele é um processo, se estamos com o OpenOffice aberto é outro processo, e por aí vai.

Aprender a lidar com processos é de extrema importância para um administrador de sistemas, pois ao manipula-los podemos através de sinais (comandos) fechá-los corretamente, fechá-los bruscamente, reiniciá-los e muitas outras coisas. É fato, que a tarefa mais básica no que se refere a processos é o que chamamos de “matar o processo”, fazemos isso quando uma aplicação está travada por algum motivo qualquer, assim fechamos ela na “força”, querendo ou não ela será fechada e permitirá que o utilizador continue utilizando o sistema normalmente e tente descobrir o que ocasionou o travamento.

Aprenderemos neste tutorial de uma forma simples como lidar com processos. Lembramos apenas que este é um assunto bastante extenso e que tem algumas variações (algumas bem significativas) com relação à outros sistemas derivados do Unix.

Na Prática

Como foi falado, tudo que está sendo executado na máquina é um processo, cada processo recebe um número de identificação aleatório, este número é exclusivo para o processo em questão enquanto ele existir, isso quer dizer que se eu abro o Firefox por exemplo, o processo que o representa receberá um número no momento em que ele é criado, enquanto o Firefox não for fechado este número não será utilizado por nenhum outro processo e mesmo que o Firefox seja aberto novamente o processo dele receberá um novo número, este número é chamado de PID que é a sigla para Process ID, ou seja, identificação do processo. O PID é fornecido automaticamente pelo Kernel.

Utilizamos o PID do processo para podermos trabalhar com ele, funciona mais ou menos como um número de RG ou CPF, podemos ter duas pessoas com o mesmo nome, porém por terem uma identificação única podemos lidar com cada uma delas sem ao menos pensarmos na possibilidade de confundir, a não ser que sejam gêmeas e tenham o mesmo nome, ué isso existe? OK, viagem pura, voltemos ao assunto. Ah, já ia esquecendo, você entendeu o raciocínio da coisa né? Podemos ter processos com nomes muito parecidos no entanto cada um terá o seu número de identificação que permitirá que o administrador trabalhe com eles sem se confundir.

Para finalizarmos o parte mais chata que é a parte teórica vamos aprender mais um conceito: Todo processo é derivado de um outro processo, exceto um, que é o primeiro processo… lógico! Então este primeiro processo é um processo chamado init, quando ligamos o computador e o sistema começa a ser carregado a primeira coisa que é carregada é o Kernel, ele vai inteiramente para a memória RAM, depois disso o Kernel carrega o init que tem o PID 1 (Um), todos os outros processos do sistema são no mínimo derivados do init. Portanto, temos aqui um conceito de processo pai, ou PPID. PPID é o PID do processo que “chamou” um determinado processo, complicado? Nem tanto. Imaginemos o seguinte: Temos o apache sendo executado em nosso servidor, o apache tem portanto um PID, fora isso, só foi possível abrir o apache porque o sistema já estava sendo executado, portanto já tinha no mínimo um processo em execução, que é o init. Neste caso o apache é um processo filho do processo init. Da mesma forma se temos um ambiente desktop instalado, como o KDE, para utiliza-lo precisamos do servidor gráfico, portanto ao inicializar o sistema temos o init que abrirá o servidor gráfico que por sua vez abrirá o KDE, e através do KDE podemos abrir o K3B por exemplo. Veja abaixo uma representação disso:

(Pai do Servidor Gráfico)

Processo Init \

(Filho do init e pai do KDE)

Servidor Gráfico \

(Filho do Servidor Gráfico e Pai do K3B)

KDE \

(Filho do KDE)

K3b

Você pode usar o comando pstree para ver os processos em forma de árvore e saber quem é “pai” de quem:

$ pstree

Porque precisamos falar sobre isso? Basicamente para deixar claro que o que você faz em um processo pai pode interferir no processo filho, principalmente se fecharmos um processo pai, saiba que neste caso o processo filho será fechado também.

Eu falei que a história do PPID será a última coisa para fechar a parte teórica? Mas não será :) , mas não fiquem bravos, vamos pelo menos aprender um comando para continuarmos com a parte teórica, trata-se do comando ps e sua forma de utilização mais comum é utilizando os argumentos aux, como em:

# ps aux
  • ps é o comando em si que utilizamos para listar os processos atuais. Sem parâmetro ele mostra apenas os processos da sessão atual (terminal atual).
  • A letra a serve para mostrar os processos de todos os usuários e não apenas do usuário que executou o comando ps.
  • A letra u indica ao ps que ele deve mostrar o nome do usuário dono do processo em questão (quem o executou).
  • E por último, mas não menos importante, a letra x que diz ao ps para listar inclusive os processos da parte gráfica e de outros terminais.

Vamos pegar uma linha do resultado para analisar:

USER PID %CPU %MEM VSZ  RSS TTY STAT START TIME COMMAND
root 1   0.0  0.1  2044 988 ?   Ss   19:15 0:01 /sbin/init

Podemos visualizar facilmente acima o nome do usuário dono do processo (USER) que é o root, o número de PID do processo que é 1 e o nome do processo que é /sbin/init (na verdade o cominho completo do executável, o processo em si se chama apenas init)

As outras informações não são tão comuns de se utilizar, no entanto segue uma descrição de cada uma delas:

  • %CPU: Porcentagem de uso do processo pelo processo.
  • %MEM: Porcentagem de uso de memória RAM pelo processo.
  • VSZ e RSS: Páginação (Tamanho do processo).
  • TTY: Terminal que originou o processo.
  • STAT: R, S, D, Z e T
    • R – Running (Rodando)
    • S – Sleep (Esperando)
    • D – Died (Morto)
    • Z – Zumbie (Erro)
    • T – Stopped (Parado)
    • Variações:
      • < – Prioridade maior que a padrão
      • N – Prioridade menor que a padrão
      • T – Processo em foreground
      • s – Dono da sessão (Pai)
      • w – Usando recurso swap
  • TIME: Tempo de CPU que o processo utilizou até o momento

Agora que já sabemos como visualizar os processos ativos na máquina com o comando ps, podemos aprender que todos os processos estão em uma espécie de fila, ou seja, os processos não estão sendo executados ao mesmo tempo como parece, eles só podem ser executados um de cada vez, mas quem manipula isso é o Kernel e ocorre de forma tão rápida que é imperceptível durante a utilização normal do sistema. Só conseguimos ter uma idéia visual que trata-se realmente de uma fila se utilizarmos um programa que mostra em tempo real e constantemente na tela cada um dos processos, para isso podemos usar o comando top:

Repare (e decore se possível) que cada sinal tem um número que o corresponde, isso pode ser observado nos números que estão entre parenteses, apesar de podemos enviar sinais utilizando seus nomes, não é muito usual fazer sso, por isso vamos usar nos exemplos sempre os números.Vamos usar o processo do vim novamente como exemplo e enviar inicialmente um SIGKILL (9) para ele, assim forçaremos seu fechamento:

$ vim teste
$ ps aux | grep vim

USER    PID  %CPU %MEM VSZ  RSS  TTY   STAT START TIME COMMAND
leandro 9820 0.0  0.1  3932 1476 pts/0 S+   20:48 0:00 vim teste
$ kill -9 9820
$ ps aux | grep vim

Atenção: Ao abrir o vim em um determinado terminal você ficará impossibilitado de executar os próximos comandos mostrados acima, portanto, você deve abrir o vim (primeiro comando) em um terminal e depois alternar para outro terminal com a combinação de teclas Ctrl + Alt + F2 (Ou F3, F4 e assim por diante até o F6), ou caso esteja utilizando um terminal no modo gráfico procure pela opção que permita abrir uma nova aba e fique alternando entre os dois terminais. Por último você terá que voltar para o terminal que estava anteriormente para ver o resultado. Trabalhe um pouco com isso pois utilizaremos muito neste capítulo.

Na seqüência acima, nós fizemos o seguinte:

  • Abrimos o vim dizendo que o nome do arquivo a ser aberto é teste.
  • Executamos o ps aux e filtramos o resultado dele com o grep para retornar somente as linhas que contenham a palavra vim.
  • Achamos o número de PID do vim no resultado do ps aux e enviamos um sinal 9 (SIGKILL) para ele.
  • Executados novamente o ps aux para verificar se o processo ainda existe.

Atenção: O sinal de menos (-) antes do número correspondente ao sinal em nada tem haver com o esquema de prioridades que vimos anteriormente, ele é apenas parte da sintaxe de utilização do comando kill, sem o sinal de menos (-), no caso do Linux, o sinal não será interpretado corretamente.

No exemplo acima nós matamos o vim como foi falado, caso ele estivesse travado ou não estivesse fechando por vias normais ao enviar um sinal 9 para ele, com certeza este seria fechado, em casos normais então nem se fala, como podemos constatar, matamos o processo dele mesmo sem ter nenhum problema relacionado, apenas para fins didáticos.

A utilização do vim como exemplo não foi por acaso, ele é um programa bom para demonstrar sinais, pois ele se comporta de forma esperada na maioria dos sinais que enviamos, diferente de outros programas mal escritos que não sabem lidar com “todos” os sinais e por isso apresentam comportamento estranho ao enviarmos certos tipos de sinais.

Ainda com o vim, vamos enviar um sinal 15 dessa vez pedindo para que o ele feche ao invés de fecha-lo bruscamente:

$ vim
$ ps aux | grep vim

USER    PID  %CPU %MEM VSZ  RSS  TTY   STAT START TIME COMMAND
leandro 6650 0.0  0.1  3932 1432 pts/0 S+   20:37 0:00 vim
$ kill -15 6650
$ ps aux | grep vim

Atenção: A primeira impressão que temos é que o sinal 15 funcionou exatamente como o sinal 9, porém se formos comparar, ao enviar um sinal 9 para o vim e voltar para o terminal que ele estava aberto, vamos perceber que ele fechou sem aviso nenhum, ou seja, foi pego de surpresa e fechado bruscamente. Ao enviarmos o sinal 15 e voltar ao terminal que o vim estava aberto nos deparamos com a mensagem “Finalizado”, indicando que o fechamento ocorreu normalmente, como se tivéssemos fechado ele manualmente.

Ficou claro a diferença entre o sinal 9 e 15? Um matará o processo e o outro fechará, respectivamente, a diferença você entende melhor ao ler o parte Atenção” acima.

Vamos agora utilizar o sinal SIGHUP (1) que faz com que um processo releia seu arquivo de configuração caso isso seja possível, como assim se for possível? Bem, não são todos os processos que sabem ou devem lidar com todos os sinais, no caso do SIGHUP se for enviado para um processo que não saiba interpreta-lo, este será fechado ao invés de reler seu arquivo de configuração e continuar executando. Este sinal é muito útil quando o processo em questão trata-se de uma aplicação servidora de algum serviço, como um servidor web, de e-mail, proxy e etc, pois temos a possibilidade de alterar sua configuração e fazer com que ela entre em vigor sem que o serviço fique fora do ar (nem mesmo por um segundo).

Como o vim fecha ao enviamos um sinal SIGHUP vamos utilizar como exemplo o processo do squid, dessa forma:

$ ps aux | grep squid

USER  PID   %CPU %MEM VSZ   RSS   TTY STAT START TIME COMMAND
proxy 15116 1.4  22.4 19372 17608 ?   S    09:14 1:12 (squid) -D -sYC
# kill -1 15116
$ ps aux | grep squid

USER  PID   %CPU %MEM VSZ   RSS   TTY STAT START TIME COMMAND
proxy 15116 1.4  22.4 19372 17608 ?   S    09:14 1:12 (squid) -D -sYC

Na seqüência acima achamos o processo do squid, identificamos o seu PID e enviamos um sinal 1 que corresponde ao SIGHUP. Por último verificamos que o processo continua existindo e com o mesmo número PID, portanto, não foi fechado e aberto novamente, pois caso isso tivesse ocorrido o número de PID seria diferente. O fato de o processo ter recebido sinal 1 e não ter renovado o seu número PID já caracteriza que o mesmo se comportou como o esperado, pois caso contrário ou o processo não existiria mais ou estaria com um novo número de identificação.

Fica difícil ilustrar o SIGHUP na prática via escrita neste curso, já que não tem foco em servidores, mas se você já configurou ou vai configurar algum tipo de servidor, provavelmente vai alterar as configurações dele e querer que elas entrem em ação, neste caso você tem duas possibilidades consideradas “normais”, uma é reiniciar o serviço como vimos no capítulo de serviços:

# /etc/init.d/squid restart

A outra é ao invés de reiniciar o serviço (que deixará o serviço fora do ar) , usar o parâmetro reload:

# /etc/init.d/squid reload

Assim o serviço não ficará fora do ar, apenas lerá o arquivo de configuração novamente em tempo real. Mas porque é que voltamos a falar de serviços se este capítulo já passou? Apenas para mostrar que ao usarmos o parâmetro reload o script do serviço irá na verdade enviar um SIGHUP para o processo correspondente a ele. Agora as coisas começam a se encaixar….

Antes de falarmos dos sinais 18 e 19 vamos facilitar as coisas já que você deve ter percebido que apesar do comando ps aux nos trazer informações valiosas, muitas vezes apenas nos interessa número de identificação de um determinado processo. Quando este for o caso, podemos substituir o ps aux pelo comando piof ou pgrep:

$ pidof firefox

11252

$ pgrep firefox

11252


Como visto acima os dois funcionam da mesma forma e tem o mesmo propósito, exibir o número PID de um determinado processo ao informarmos via parâmetro o nome deste. O pidof costuma ser mais preciso no resultado, pois o pgrep em muitos casos se confunde no resultado e acabada trazendo outros processos que por um motivo ou outro também contém a string especificada via parâmetro.

Vamos ao SIGSTOP (19) e SIGCONT (18). Falaremos deles em conjunto pois um complementa a funcionalidade do outro, enquanto o SIGSTOP nos permite dar uma “pausa” em um processo, o SIGCONT faz com que possamos continuar um processo que está parado. Ao enviarmos um sinal 19 para um processo, este deixa de consumir recursos da máquina, mas não perde seu estado atual, ou seja, pode continuar de onde parou quando for da vontade do administrador.

Atenção: O processo que recebe um sinal SIGSTOP não perde seu estado atual somente se o processo em questão não for “morto” em seguida. Isso quer dizer que você não pode pausar um processo, desligar a máquina e restaura-lo depois de inicializar, pois quando desligamos ou reinicializamos o sistema todos os processos recebem um SIGTERM ou SIGKILL.

Imagina a cena. Você tem um determinado diretório com uma quantidade absurda de arquivos, como você é uma pessoa atenta, já que tem tantos arquivos, decide fazer um backup deles para evitar problemas futuros, para isso irá utilizar o tar e compressão bzip2, deve demorar um pouco, já que são muitos arquivos, certo? Não é só o fato de demorar que pode incomodar fazer backup, muitas vezes consume uma quantidade boa de recursos da máquina, principalmente porque o acesso ao HD fica a todo vapor, tornando a máquina muitas vezes inútil enquanto o backup está ocorrendo. Dentro deste cenário, com o backup já em andamento, seu chefe te pede um determinada documento o mais rápido possível, na linguagem que estamos acostumados a ouvir, seria “Pra ontem”, para piorar a situação você não faz idéia de onde guardou o arquivo em questão e terá que procurar.

E aí? Você pára o backup para recomeçar depois e perde o que já foi feito ou espera terminar e corre o risco de ter a atenção chamada? Usando os sinais você pode simplesmente pausar o tar e continuar depois, assim enquanto ele estiver parado você terá liberdade e conforto para trabalhar com outras coisas, como procurar o arquivo e abri-lo no OpenOffice por exemplo.

É claro que o conto acima é apenas uma ilustração para podermos trabalhar em cima do assunto, a idéia é que você desenvolva o conteúdo e aplique nas suas próprias necessidades.

Simularemos um backup de toda nossa partição raiz em um arquivo que será gerado na própria partição, apenas para fins didáticos já que o correto seria gera-lo em outro HD, partição, Pen Drive, ou qualquer outra mídia removível. Em seguida iremos enviar um SIGSTOP, checar o seu estado, enviar um SIGCONT e checar seu estado novamente:

# tar cjvf /backup.tar.bz2 /
# ps aux | grep tar

USER PID  %CPU %MEM VSZ  RSS  TTY   STAT START TIME COMMAND
root 6835 0.6  0.1  3544 1156 pts/0 S 19:13 0:00 tar cjvf /backup.tar.bz2 /
# kill -19 6835

# ps aux | grep tar

USER PID  %CPU %MEM VSZ  RSS  TTY   STAT START TIME COMMAND
root 6835 0.0  0.1  3544 1220 pts/0 T    19:13 0:00 tar cjvf /backup.tar.bz2 /

Atenção: Ao executar o comando tar em um determinado terminal você ficará impossibilitado de executar os próximos comandos mostrados acima, portanto, você deve executar o tar (primeiro comando) em um terminal e depois alternar para outro terminal com a combinação de teclas Ctrl + Alt + F2 (Ou F3, F4 e assim por diante até o F6), ou caso esteja utilizando um terminal no modo gráfico procure pela opção que permita abrir uma nova aba e fique alternando entre os dois terminais. Por último você terá que voltar para o terminal que estava anteriormente para ver o resultado.

É bom darmos uma pausa por aqui antes de enviarmos um SIGCONT para o processo que acabamos de parar para falar que a informação mais importante neste momento é o conteúdo da coluna STAT pois ela que nos dirá o estado atual do processo, como visto anteriormente a letra S significa que o processo está em execução mas está em espera, ou seja, não está neste exato momento consumindo recursos do processador, mas pode começar a qualquer momento. A letra T por outro lado nos informa que o processo está parado, como esperávamos que estivesse realmente, afinal enviamos um SIGSTOP para ele.

Outra observação é que conforme você deve ter percebido ao paramos um processo com o sinal 19 o processo ficará em background, isso quer dizer que as informações que o tar fornece na tela não serão mais exibidas e poderemos utilizar o terminal que estava preso pelo processo do tar.

# kill -18 6835
# ps aux | grep tar

USER PID  %CPU %MEM VSZ  RSS  TTY   STAT START TIME COMMAND
root 6835 0.0  0.1  3544 1220 pts/0 S 19:13 0:00 tar cjvf /backup.tar.bz2 /

Ao enviarmos o sinal 18 o processo volta a ser executado conforme observado na coluna STAT, mas fora isso, se voltarmos ao terminal onde o tar estava sendo executados podemos observar seu funcionamento novamente.

Por enquanto é isso, espero que tenham gostado.

Fonte: www.guiadohardware.net

Enviado em Linux, Tecnico | Deixar um comentário »