Squid, Iptables, Sarg, SaMBa e Apache

Pessoal achei muito interessante este tutorial publicado por Tiago Cruz em 6 de julho de 2007 às 16h06 no site www.guiadohardware.com.br então decidi transcrevê-lo

Introdução

Aviso importante

Olá gente! Tive um contato com alguns servidores e achei legal deixar anotado os passos que fiz para configurar uma máquina semi-morta compartilhando o acesso a internet junto com um firewall protegendo-a.

Já adianto para os chatos de plantão que este documento é feito por mim e para mim! Outra: Se quiser um manual avançado sobre tudo isso procure outro artigo/ tutorial na NET. No final do texto tem alguns links interessantes, pode ir direto para lá.

Meu objetivo aqui é somente reunir umas dicas que achei legal, sem escrever especificamente sobre determinado assunto.

Introdução

Bom, o que rola é que tive que compartilhar um adslmodem para 10 estações, controlar o acesso a NET e deixar a mesma protegida sem gastar U$ 600,00 que é o valor de um firewall/ router em hardware da blackbox (isso é somente um exemplo). Na verdade eu queria mesmo é me divertir com o que tinha em mãos =)

O "Hardware"

Como disse anteriormente, a "máquina" semi-morta estava encostada aqui, porque ela congela geral a cada 5 minutos no windows 98 ou no 95. Troquei tudo, menos a placa-mãe, uma famiguerada PC-Chips M812 LMR... com o KDE/Fluxbox não foi diferente, congelava direto e reto!

Depois de umas duas horas de tentativas (congelava direto), consegui instalar o Kurumin 1.4 no HD e arrancar o modo gráfico dela... hehehehe... agora parece que estabilizou, em modo texto. Deixei ele calculando o valor de 'pi' com 10000 casas decimais, o processador ficou ocupado por muuiito tempo e retornou o valor correto (quero dizer, deve estar correto) sem congelar, que é o que importa. Para quem ficou curioso:

$ echo "scale=10000; 4*a(1)" | bc -l

Bom, acompanhado à mobo zoada, tenho um Duron 950 MHz, um disco rígido de 1.9 GB e 128 MB de RAM DIM PC-100 MHz. Som e modem on-board desabilitado, rede SiS900 ok.

Configuração

Depois do parto para instalar, começa-se a configuração (a parte mais legal)! Como a máquina estava em um ambiente de teste, sob um proxy, coloquei as variáveis dela em /etc/environment... mas não funcionou (pow, da última vez tinha funcionado... :-/ ). Ok, sem stress, coloquei em /etc/profile e ficou tudo certo:

export ftp_proxy="http://192.168.0.1:80"
export http_proxy="http://192.168.0.1:80"

Agora sim, com apt "em mãos" eu pude detonar tudo:

# apt-get update
# apt-get remove xdm kdm kopete gaim [...]

Removi uma porrada de 'tranqueira' que não será usado em um servidor sério como este :) Depois dei um '# apt-get update' e deixei o bixo atualizadinho... mas o X parou de subir... até tentei uns kxconfig e mkxf86config mas depois desisti e acabei arrancando tudo que começava com kde ('dpkg -l kde*') e o pacote 'sudo' também (odeio ele, heheh).

Está ficando interessante! Estava tudo ok para iniciar os testes, mas faltava uma placa de rede! Depois de arrancar uma 3Com509B PCI de um micro aqui, espetar, rodar o hwsetup e descobrir que após o boot eu perco o módulo da placa, adicionar a mesma (o módulo chama-se 3c59x) em /etc/modules para que carregue durante o boot, pude continuar com os servidores em si.

Antes de mais nada, tirei a máquina de seu local de testes e levei-a junto de um teclado velho a seu lugar definitivo, em outro prédio.

Configurando o adslmodem e rede interna

Boiada. Pensei que era pior. Com o comando netcardconfig configurei a eth0 (sis900) como local (192.168.0.1 / 255.255.255.0) e a eth1 (3com) com os dados passados pelo 'tiuzinho' que instalou o speed: IP, gateway, DNS's... e pronto, a net já funcionou! Ainda bem que o IP é fixo, heheheh...

Só uma coisa que tive que fazer é retirar as variáveis de proxy do /etc/profile... senão o apt não iria funcionar mesmo :-/

Compartilhando a NET para os outros micros da rede

Essa parte é fácil, e já está bem manjada:

modprobe iptable_nat
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

Nas estações, basta configurar um IP tipo 192.168.0.2 / 255.255.255.0, o gateway deve ser a maquina com linux (192.168.0.1) e o DNS o do seu provedor (o do Terra, por exemplo: 200.204.0.10)

Na verdade, andei testando, e parece que nem precisa do DNS... mas se der algum problema, basta coloca-lo...

Se quiser fazer sempre isso, em todos os boots, adicione essas linhas no seu /etc/init.d/bootmisc.sh (Debian/ Kurumin) ou em /etc/rc.d/rc.local (Mandrake / Red Hat)

Eu poderia ter parado por aqui... mas como disse, não teria graça... quero brincar com o squid e com o sarg, ainda! E mexer mais com o iptables também!

Squid: Controle de acesso a NET

Instalei o dito-cujo

apt-get install squid

Mas "deu um erro"... removi e instalei de novo... o erro continuava. Apaguei ele de /var/cache/apt/archives, removi com um dpkg --purge e instalei de novo... deu erro... arrrgghhhh!

Resolvi ler o erro que estava dando (quem nunca fez isso atire o primeiro mouse :) ah... ele ta falando que eu não defini um tal de 'visible_hostname'

# vi /etc/squid.conf
/visible_hostname [enter]

Achei o danado... tem uma descrição mas não mostra um exemplo de uso :-/

Tentei:

visible_hostname="kurumin.proxy"
visible_hostname=kurumin.proxy
visible_hostname "kurumin.proxy"
visible_hostname kurumin.proxy

Até achar um que não reclamasse mais nos logs... que por sinal era o último (maldita lei de murphy...)

Para testar o benedito, adicionei essas linhas na parte das ACL's:

acl rede_interna src 192.168.0.0
http_access allow rede_interna
http_access deny all

Inicia-se o cara:

/etc/init.d/squid start

E testa em uma estação, tomando o cuidado para configurar a mesma para usar a internet via proxy, no IP do servidor linux e a porta 3128 (padrão)

Funcionou? Legal, agora temos um cache de navegação, que deixa a coisa mais rápida e logs de acesso para controlar o povo... muito bom!

Mas se o engraçadinho tirar a opção de navegar com o proxy, ele navega sem ficar logado nada... isso não pode acontecer:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to 3128

Agora sim... ta ficando legal!

Dá para fazer mais uma porrada de coisas legais com o squid, mas de momento, só farei mais uns ajustes no arquivo de configuração dele, nada muito complexo ficando assim:

http_port 3128
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin ?
no_cache deny QUERY
cache_mem 64 MB
cache_access_log /var/log/squid/access.log

acl all src 192.168.0.0/255.255.255.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
acl rede_interna src 192.168.0.0

http_access allow rede_interna
http_access deny all

icp_access allow all
cache_mgr tiagocruz @ forumgdh . net
visible_hostname kurumin.proxy
logfile_rotate 10

Bom, note que eu mudei a minha 'acl all src' restringindo somente a minha rede interna. Dica de um colega e colaborador do LinuxRapido, o usuário Challado:

"E uma coisa importante de lembrar pra você, é mudar a configuração da variável all, que está na seguinte ACL:

acl all src 0.0.0.0

para:

acl all src {Endereço ip da sua rede interna}

Porque se não (principalmente se no servidor onde você rodará esse squid você tiver um IP válido você poderá estar criando mais um servidor para ajudar os spammers a espalhar o spam pela net."

Note também que estou dedicando 64 MB para o squid, já que tenho 128 MB e não vou usar modo gráfico...

Outra coisa que você deve estar estranhando é que meu arquivo está bem resumido, sem os comentários... hehehhe... a mágica está aqui (digite no diretório do mesmo):

# cp squid.conf squid.conf.back
# grep -v ^# squid.conf.back|grep -v ^$ > squid.conf

Agora que está tudo legal, vamos ver nos logs o que a galera está fazendo:

# tail -f /var/log/squid/

"Nossa que zona!" Você pensou? Eu também... vamos para a próxima parte deste artigo:

Sarg: Embelezando os logs de acesso

O Sarg é mais um software livre, mas feito por um brazuca! O Pedro Orso está de parabéns!!! Com o sarg, temos relatórios em html com estatísticas, coisa de primeira linha que eu não tenho nem nos proxys comerciais que uso, como o Winproxy.

apt-get install sarg
vi /etc/squid/sarg.conf

Nem precisa mudar muita coisa... é rapidim:

language Portuguese
title "Relatório de uso da internet"
date_format e

E "ja era" tá ótimo! Por padrão (pelo menos no debian) ele irá jogar o relatório em /var/www/squid-reports/.

Digitando sarg, ele irá processar tudo, bonitinho e você irá se espantar com o resultado, caso nunca tenha visto antes... simplesmente fantástico! Esse cara [também] merece uma skol... isso se você tiver um navegador gráfico para visualiza-lo, no meu caso tive que compartilhar a saída do mesmo via SaMBa para poder ver alguma coisa :-p

SaMBa: Compartilhando o relatório para as máquinas windows

Como já escrevi bastante sobre o samba, serei mais direto:

# apt-get install samba
# vi /etc/samba/smb.conf
[global]
workgroup = INTERNET
netbios name = GATEWAY
server string = %h server (Samba %v)
interfaces = eth0, 192.168.0.0/255.255.255.0
security = SHARE
obey pam restrictions = Yes
passdb backend = smbpasswd, guest
passwd program = /usr/bin/passwd %u
passwd chat = *EntersnewsUNIXspassword:* %n

*RetypesnewsUNIXspassword:* %n
.
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
dns proxy = No
panic action = /usr/share/samba/panic-action %d
invalid users = root

[squid]
comment = Relatorios do SQUID
path = /var/www/squid-reports
guest ok = Yes

# /etc/init.d/samba start

Bom, como o servidor está direito na Internet, em poucos minutos já apareceu nos logs um monte de prováveis máquinas windows infectadas procurando um compartilhamento 'c' no meu servidor... por isso, restringi o acesso somente à interface 'eth0' (local).

Agora... tenho que bolar um modo de mostrar esse relatório para meu chefe, que está em outro prédio, sem acesso a essa rede...

Apache: Servidor web quebrando um galhão

Foi fácil demais... :-p

# apt-get install apache
# vi /etc/apache/httpd.conf

Nem precisa mudar muita coisa... só uma alteraçãozinha para não mostrar a versão do mesmo, para dificultar um pouco o povo que gosta de invadir os servidores por ae: :-)

Se sua porta 80 estiver bloqueada (speed home) terá que usar outra...

Port 80
ServerSignature Off
ServerTokens Prod

Iniciando...

# /etc/init.d/apache start

Agora sim! De qualquer lugar, digitando http://ip.do.server eu chego nos tão esperados relatórios de acesso a internet! :) :) :)

Como um ótimo complemento, vou deixar aqui a dica de outro usuário do site, o Guilherme Straioto:

" Use o apache com autenticação de usuário, para apenas o pessoal da TI poder ver os relatórios como aqui na empresa... abaixo como fiz, senão você sabe vira festa:

No httpd.conf, edite as tag DocumentRoot e Directory :

DocumentRoot "/var/www/squid-reports/"

e logo abaixo:

AuthName "Area restrita, para Sarg"
AuthType Basic
AuthUserFile /etc/.htpasswd
require valid-user
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all


# AuthUserFile: é onde esta o arquivo de senha e usuário
# require valid-user: aqui pedirá a tela de autenticação qdo solicitado

Agora só criar os usuários com permissão ao acesso:

# htpasswd -c /etc/.htpasswd ti

Pronto! Apenas o usuario ti após autenticado pelo apache terá acesso aos relatórios"

Iptables: Aumentando a segurança

Bom, não sou nenhum especialista em firewall, mas seguindo uns exemplos do Morimoto (abração pra você, velho!) e que achei na NET cheguei a isso:

#! /bin/bash
# Firewall Simples / Compartilhamento
# Carlos Morimoto 05/2003
# Tiago Cruz - 02/2004

# Carrega os módulos
modprobe ip_tables
modprobe iptable_nat

#Limpa tudo
iptables -F
iptables -t nat -F

# Para rede local receber e-mail
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

# Para nao fugirem do proxy
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to 3128

# Encaminhamento de IP
echo 1 > /proc/sys/net/ipv4/ip_forward

# Abre algumas portas (ssh e http)
iptables -A INPUT -p tcp --destination-port 22 -j ACCEPT
iptables -A INPUT -p tcp --destination-port 80 -j ACCEPT

# Abre para a rede local
iptables -A INPUT -p tcp --syn -s 192.168.0.0/255.255.255.0 -j ACCEPT

# Proteções diversas contra portscanners, ping of death, ataques DoS, etc.
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -A FORWARD -p tcp -m limit --limit 1/s -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
iptables -A FORWARD --protocol tcp --tcp-flags ALL SYN,ACK -j DROP
iptables -A FORWARD -m unclean -j DROP

# Fecha o resto
iptables -A INPUT -p tcp --syn -j DROP

# Se você quiser que o PC também não responda a pings, adicione a linha:
# echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

Basta colocar ele nos scripts de inicialização como dito anteriormente, se desejar isso.

Crontab: Automatizando o processo

Vamos agendar algumas coisas legais no crontab:

root@kurumin:/home/tiago# crontab -l
00 12 * * 1-1 apt-get update && apt-get upgrade -y

00 17 * * 1-5 /usr/sbin/squid -k rotate > /dev/null
00 16 * * 1-5 /usr/bin/sarg

A primeira linha deixa seu servidor sempre atualizado, todas as segundas-feiras ao 12:00.

A segunda linha "roda" os logs do squid (definidos em 'logfile_rotate 10' lá em cima, o que significa que será criado logs de 0 a 9 para não acabar com seu espaço no HD e travar tudo :)

Veja essa dica do meu colega, usuário Jqueiroz sobre os logs:

"Defina quantos arquivos antigos manter: logfile_rotate n

Coloque no crontab o comando abaixo pra rodar o log 1 ou 2 vezes /dia. Aqui (300 máquinas), rodando 2x/dia o access.log fica +- 30MB.

/usr/bin/squid -k rotate > /dev/null

Nota: fazendo 2x/dia, escolha bem a hora em que faz, senão você fica com 1 enorme e outro quase vazio. Eu faço às 3h00 e às 15h00."

A última linha, atualiza seus logs do sarg, as 16:00 de segunda a sexta.

Agradecimentos

Bom gente, gostaria de deixar registrado aqui meus agradecimentos a todos que me ajudaram ou que dedicam seu tempo livre documentando e/ou ajudando outras pessoas ao redor do mundo apoiando o software livre.

Em especial, ao povo citado durante o documento que tiveram bastante paciência em me ajudar, diretamente ou indiretamente (respondendo a outros usuários, por exemplo), passando dicas, dando sugestões e etc.

Valeu mesmo!

Referência: http://www.hardware.com.br/artigos/rapidinhas/
Copiado em : 26/11/2011 - 18:44

Bloqueando por domínios ou palavras no SQUID

O Squid permite bloquear sites indesejados de forma bastante simples usando o parâmetro "dstdomain". Ele permite que você crie acl's contendo endereços de sites que devem ser bloqueados (ou permitidos). Isso é feito em duas etapas. Primeiro você cria a acl, especificando os endereços e, em seguida, usa o parâmetro "http_access" para bloquear ou liberar o acesso a eles.

Veja um exemplo:

acl bloqueados dstdomain orkut.com playboy.abril.com.br
http_access deny bloqueados

Aqui eu criei uma acl chamada "bloqueados", que contém os endereços "orkut.com" e "playboy.abril.com.br" e em seguida usei o parâmetro "http_access deny" para bloquear o acesso a eles. Você pode incluir diversas acls diferentes dentro da configuração do Squid, desde que use um nome diferente para cada uma. De certa forma, elas são similares às variáveis, que usamos ao programar em qualquer linguagem.

Ao aplicar a regra, o Squid faz a resolução do domínio e passa a bloquear todas sub-páginas que estiverem hospedadas dentro dele. Existe uma ressalva: muitos sites podem ser acessados tanto com o "www" quanto sem. Se os dois estiverem hospedados em servidores diferentes, o Squid considerará que tratam-se de dois sites diferentes, de forma que ao bloquear apenas o "www.orkut.com" os usuários ainda conseguirão acessar o site através do "orkut.com" e vice-versa.

Nesses casos, para bloquear ambos, é preciso incluir as duas possibilidades dentro da regra, como em:

acl bloqueados dstdomain orkut.com www.orkut.com playboy.abril.com.br
http_access deny bloqueados

Você pode incluir quantos domínios quiser dentro da acl, basta separá-los por espaço e deixar tudo na mesma linha. Se a regra começar a ficar muito grande, você tem a opção de transferir as entradas para um arquivo.

Nesse caso, crie um arquivo de texto simples, com todos os domínios desejados (um por linha), como em:
orkut.com
www.orkut.com
playboy.abril.com.br
www.myspace.com

... e use a regra abaixo na configuração do Squid para que ele seja processado e os domínios sejam incluídos na acl. No exemplo, estou usando o arquivo "/etc/squid/bloqueados":

acl bloqueados url_regex -i "/etc/squid/bloqueados"
http_access deny bloqueados

Naturalmente, não seria viável tentar bloquear manualmente todos os sites pornográficos, chats, comunidades online, e todos os outros tipos de sites que não são úteis em um ambiente de trabalho. A idéia seria logar os acessos (com a ajuda do Sarg, que veremos mais adiante) e bloquear os sites mais acessados, conforme tomar conhecimento deles. É sempre uma corrida de gato e rato, mas, em se tratando de pessoas adultas, não há nada que uma boa conversa com o chefe não possa resolver. ;)
De qualquer forma, em alguns ambientes pode ser mais fácil bloquear inicialmente o acesso a todos os sites e ir abrindo o acesso a apenas alguns sites específicos, conforme a necessidade. Neste caso, invertemos a lógica da regra.

Criamos um arquivo com sites permitidos, adicionamos a regra que permite o acesso a eles e em seguida bloqueamos o acesso a todos os demais, como neste exemplo:

acl permitidos url_regex -i "/etc/squid/permitidos"
http_access allow permitidos
http_access deny all

Nas versões recentes do Squid, ao bloquear um domínio é automaticamente bloqueado também o endereço IP do servidor correspondente. Isso evita que os usuários da rede consigam burlar o proxy, acessando os sites diretamente pelo IP. De qualquer forma, você pode criar diretamente regras que bloqueiem determinados endereços IP, o que é útil em casos de servidores sem domínio registrado, ou que respondam por vários domínios. Nesse caso, a regra ficaria:

acl ips-bloqueados dst 200.234.21.23 200.212.15.45
http_access deny ips-bloqueados

Você pode descobrir rapidamente o endereço IP de um determinado domínio usando o comando

"host", como em:

$ host google.com

google.com A 72.14.207.99
google.com A 64.233.187.99
google.com A 64.233.167.99

Depois de adicionar as novas regras, nosso arquivo de configuração ficaria assim:

http_port 3128
visible_hostname gdh
error_directory /usr/share/squid/errors/Portuguese/
cache_mem 64 MB
maximum_object_size_in_memory 64 KB
maximum_object_size 512 MB
minimum_object_size 0 KB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /var/spool/squid 2048 16 256
cache_access_log /var/log/squid/access.log
refresh_pattern ^ftp: 15 20% 2280
refresh_pattern ^gopher: 15 0% 2280
refresh_pattern . 15 20% 2280
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

acl bloqueados url_regex -i "/etc/squid/bloqueados"
http_access deny bloqueados

acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all


Veja que coloquei as duas regras antes do "http_access allow redelocal", que abre tudo para a rede local. Como o Squid processa as regras seqüencialmente, as páginas que forem bloqueadas pela acl "bloqueados" não chegam a passar pela regra que autoriza os acessos provenientes da rede local.
Uma segunda possibilidade é usar o parâmetro "dstdom_regex", que permite bloquear sites de uma forma mais geral, com base em palavras incluídas na URL de acesso. Você pode bloquear todas as páginas cujo endereço inclua a palavra "sexo" ou "orkut", por exemplo. Note que, ao usar esta regra, o Squid verifica a existência das palavras apenas na URL do site e não no conteúdo da página. Para criar filtros baseados no conteúdo, você pode utilizar o DansGuardian, que veremos mais adiante.
Crie mais um arquivo de texto, contendo as palavras que devem ser bloqueadas, uma por linha, como em:
orkut
xxx
sexo
teens
warez


... e adicione a regra abaixo, contendo a localização do arquivo:

acl palavrasproibidas dstdom_regex "/etc/squid/palavrasproibidas"
http_access deny palavrasproibidas

O uso desta regra é um pouco mais problemático, pois bloqueará todas páginas que contenham qualquer uma das palavras listadas na URL. Esta opção sempre levará a alguns falsos positivos e por isso deve ser usada com mais cuidado.

Uma vantagem é que ela permite bloquear facilmente páginas dinâmicas, onde a palavra é passada como parâmetro da URL. Um exemplo é o Orkut, onde, depois da transferência para o Google, os domínios principais passaram a encaminhar para URLs dinâmicas dentro do domínio do Google, como em:

https://www.google.com/accounts/ServiceLogin?service=orkut&continue=http%3A%2F%2Fwww.orkut.com
%2FRedirLogin.aspx%3Fmsg%3D0%26page%3Dhttp%253A%252F%252F
www.orkut.com%252FHome.aspx&hl=pt-BR&rm=false&passive=true


Você não poderia simplesmente bloquear o domínio "google.com" usando uma regra url_regex, mas poderia muito bem usar o dstdom_regex para bloquear a palavra "orkut" e assim bloquear o acesso ao site sem bloquear o acesso a outros serviços do Google.

Não existe problema em combinar o bloqueio de domínios e de palavras dentro da URL, você pode lançar mão de uma combinação das duas coisas, de acordo com a situação. Para isso, basta usar as duas regras simultaneamente, como em:

acl bloqueados url_regex -i "/etc/squid/bloqueados"
http_access deny bloqueados

acl palavrasproibidas dstdom_regex "/etc/squid/palavrasproibidas"
http_access deny palavrasproibidas

acl redelocal src 192.168.1.0/24
http_access allow localhost
http_access allow redelocal
http_access deny all


Incluídas as regras, os clientes passam a ver uma mensagem de erro ao tentar acessar páginas que se enquadrem nos bloqueios:

Por padrão, as mensagens de erro aparecerem em inglês. No nosso caso elas estão aparecendo em português devido à linha "error_directory /usr/share/squid/errors/Portuguese/" que incluí no modelo de configuração anterior.

Você pode personalizar as páginas de erro editando os arquivos dentro da pasta "/usr/share/squid/errors/Portuguese" ou "/usr/share/squid/errors/English" (de acordo com a língua definida na configuração). A pasta contêm várias páginas html, uma para cada tipo de erro indicado.

Referência:  http://www.hardware.com.br/livros/servidores-linux/bloqueando-por-dominios-palavras.html
Copiado em : 26/11/2011 - 18:35

Configurando o proxy transparente no SQUID

O Squid permite compartilhar a conexão entre vários micros, servindo como um intermediário entre eles e a internet. Usar um proxy é diferente de simplesmente compartilhar a conexão diretamente, via NAT.

Ao compartilhar via NAT, os micros da rede acessam a internet diretamente, sem restrições. O servidor apenas repassa as requisições recebidas, como um garoto de recados. O proxy é como um burocrata que não se limita a repassar as requisições: ele analisa todo o tráfego de dados, separando o que pode ou não pode passar e guardando informações para uso posterior.

Um dos principais problemas de usar um proxy é que você precisa configurar manualmente cada micro da rede para utilizá-lo, o que é um trabalho cansativo e tedioso, sobretudo em grandes redes.

O Squid responde a este desafio com a possibilidade de criar um proxy transparente, onde o proxy se integra a uma rede já existente, acelerando a conexão, mas sem precisar de qualquer configuração nos clientes.

Ao usar um proxy transparente, você tem basicamente uma conexão compartilhada via NAT, com a mesma configuração básica nos clientes. O proxy entra na história como um adicional. Uma regra de firewall envia as requisições recebidas na porta 80 do servidor para o proxy, que se encarrega de responder aos clientes. Toda a navegação passa a ser feita automaticamente através do proxy (incluindo o cache dos arquivos do Windows update, downloads diversos e os pacotes instalados através do apt-get), sem que você precise fazer nenhuma configuração adicional nos clientes :).

Mesmo que alguém tente desabilitar o proxy manualmente nas configurações do navegador, ele continuará sendo usado. Basta usar o endereço IP do servidor rodando o proxy como gateway da rede.

Lembre-se de que, para usar o proxy transparente, você já deve estar compartilhando a conexão no servidor via NAT e, naturalmente, já deve estar com um servidor Squid configurado.

Você aprende a configurar o Squid em detalhes no capítulo 5 do livro Redes e Servidores Linux 2ed. Você pode também ler meu tutorial antigo, disponível no: http://www.hardware.com.br/tutoriais/configurando-servidor-proxy-squid/.
Para ativar o proxy transparente, rode o comando abaixo. Ele direciona as requisições recebidas na porta 80 para o Squid:
# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
O "eth0" no comando indica a placa da rede local, onde o proxy recebe as requisições dos outros micros da rede e o "3128" indica a porta usada pelo Squid. Adicione o comando junto com os 4 comandos que compartilham a conexão no final do arquivo "/etc/rc.d/rc.local" ou "/etc/init.d/bootmisc.sh" (no Debian) para que eles sejam executados durante o boot.Finalmente, você precisa ativar o suporte ao modo transparente dentro do arquivo "/etc/squid/squid.conf" e reiniciar o serviço.
É aqui que entra a parte principal desta dica. A partir do Squid 2.6 a configuração de proxy transparente mudou, tornando desatualizados a maioria dos tutoriais e dicas antigos. Se você está usando uma versão recente, do Squid 2.6 em diante, a configuração de proxy transparente é feita com uma única linha. Basta substituir a linha "http_port 3128" no início do arquivo por:
http_port 3128 transparent
Ou seja, na verdade você precisa apenas adicionar o "transparent", para que o Squid passe a entender as requisições redirecionadas pela regra do firewall.
No caso das versões mais antigas, anteriores à 2.6 (como a usada no Debian Sarge e no Ubuntu 5.10), você usa a receita antiga, onde é necessário adicionar as quatro linhas abaixo, no final do arquivo "/etc/squid/squid.conf" (neste caso, sem alterar a linha "http_port 3128"):

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Em qualquer um dos dois casos, você precisa reiniciar o serviço para que a alteração entre em vigor:

# /etc/init.d/squid restart

Em caso de dúvida sobre qual versão do Squid está instalada, use o comando "squid -v", que além de reportar a versão, informa todas as opções que foram usadas durante a compilação:

# squid -v

Squid Cache: Version 2.6.STABLE2configure options: '--prefix=/usr' '--exec_prefix=/usr' '--bindir=/usr/sbin' '--sbindir=/usr/sbin' '--libexecdir=/usr/lib/squid' '--sysconfdir=/etc/squid' '--localstatedir=/var/spool/squid' '--datadir=/usr/share/squid' '--enable-async-io' '--with-pthreads' '--enable-storeio=ufs,aufs,diskd,null' '--enable-linux-netfilter' '--enable-linux-proxy' '--enable-arp-acl' '--enable-epoll' '--enable-removal-policies=lru,heap' '--enable-snmp' '--enable-delay-pools' '--enable-htcp' '--enable-cache-digests' '--enable-underscores' '--enable-referer-log' '--enable-useragent-log' '--enable-auth=basic,digest,ntlm' '--enable-carp' '--with-large-files' 'i386-debian-linux' 'build_alias=i386-debian-linux' 'host_alias=i386-debian-linux' 'target_alias=i386-debian-linux'

Em resumo, você vai ter a conexão compartilhada via NAT no servidor e configurará os clientes para acessar através dela, colocando o servidor como gateway da rede. Ao ativar o proxy transparente, a configuração dos clientes continua igual, a única diferença é que agora (graças à nova regra do Iptables) todo o tráfego da porta 80 passará, obrigatoriamente, pelo servidor Squid. Isso permite que você se beneficie do log dos acessos e do cache feito pelo proxy, sem ter que se sujeitar às desvantagens de usar um proxy, como ter que configurar manualmente cada estação.
Uma observação importante é que esta configuração de proxy transparente não funciona em conjunto com o sistema de autenticação incluso no Squid. Ao usar o proxy transparente a autenticação deixa de funcionar, fazendo com que você precise escolher entre as duas coisas. Caso você precise combinar o uso de autenticação com o proxy transparente, você precisará utilizar outra solução, como o NatACL ou o NoCatAuth, que você encontra nos links: http://www.hostname.org/proxy_auth/ e http://nocat.net/.


Referência:  http://www.hardware.com.br/dicas/configurando-proxy-transparente-nas-novas-versoes-squid.html
Retirado em : 26/11/2011 - 18:33

Criado por Carlos E. Morimoto em 31 de agosto de 2006 às 20h53

Instalando o Squid

Instalando o Squid

O Squid é composto de um único pacote, por isso a instalação é simples. Instale o pacote "squid" usando o apt-get, yum ou urpmi, como em:

# apt-get install squid

Toda a configuração do Squid é feita em um único arquivo, o "/etc/squid/squid.conf". Caso você esteja usando uma versão antiga do Squid, como a incluída no Debian Woody, por exemplo, o arquivo pode ser o "/etc/squid.conf". Apesar da mudança na localização do arquivo de configuração, as opções descritas aqui vão funcionar sem maiores problemas.
O arquivo original, instalado junto com o pacote, é realmente enorme, contém comentários e exemplos para quase todas as opções disponíveis. Ele pode ser uma leitura interessante se você já tem uma boa familiaridade com o Squid e quer aprender mais sobre cada opção, mas, de início, é melhor começar com um arquivo de configuração mais simples, apenas com as opções mais usadas.
Em geral, cada distribuição inclui uma ferramenta diferente para a configuração do proxy. Uma das mais usadas é o Webmin, disponível em várias distribuições. A função dessas ferramentas é disponibilizar as opções através de uma interface gráfica e gerar o arquivo de configuração com base nas opções escolhidas. Em alguns casos, essas ferramentas ajudam bastante, mas, como elas mudam de distribuição para distribuição, acaba sendo mais produtivo aprender a trabalhar direto no arquivo de configuração, que, afinal, não é tão complicado assim. Assim como em outros tópicos do livro, vamos aprender a configurar o Squid "no muque", sem depender de utilitários de configuração.
Comece renomeando o arquivo padrão, de forma a conservá-lo para fins de pesquisa:
# mv /etc/squid/squid.conf /etc/squid/squid.conf.orig
Em seguida, crie um novo arquivo "/etc/squid/squid.conf", contendo apenas as quatro linhas abaixo:
http_port 3128
visible_hostname gdh
acl all src 0.0.0.0/0.0.0.0
http_access allow all

Estas linhas são o suficiente para que o Squid "funcione". Como viu, aquele arquivo de configuração gigante tem mais uma função informativa, citando e explicando as centenas de opções disponíveis. Apenas um punhado das opções são realmente necessárias, pois, ao omití-las, o Squid simplesmente utiliza os valores default. É por isso que acaba sendo mais simples começar com um arquivo vazio e ir inserindo apenas as opções que você conhece e deseja alterar.
As quatro linhas dizem o seguinte:

http_port 3128: A porta onde o servidor Squid vai ficar disponível. A porta 3128 é o default, mas muitos administradores preferem utilizar a porta 8080, que soa mais familiar a muitos usuários.

visible_hostname gdh: O nome do servidor, o mesmo que foi definido na configuração da rede. Ao usar os modelos desse capítulo, não se esqueça de substituir o "gdh" pelo nome correto do seu servidor, como informado pelo comando "hostname".

acl all src 0.0.0.0/0.0.0.0 e http_access allow all: Estas duas linhas criam uma acl (uma política de acesso) chamada "all" (todos), incluindo todos os endereços IP possíveis. Ela permite que qualquer um dentro desta lista use o proxy, ou seja, permite que qualquer um use o proxy, sem limitações.
Para testar a configuração, reinicie o servidor Squid com o comando:

# /etc/init.d/squid restart
Se estiver no CentOS, Fedora ou Mandriva, pode utilizar o comando "service", que economiza alguns toques no teclado:

# service squid restart

No Slackware, o comando será "/etc/rc.d/rc.squid restart", seguindo a lógica do sistema em colocar os scripts referentes aos serviços na pasta /etc/rc.d/ e inicializá-los automaticamente durante o boot, desde que marcada a permissão de execução.
Para testar o proxy, configure um navegador (no próprio servidor) para usar o proxy, através do endereço 127.0.0.1 (o localhost), porta 3128. Se não houver nenhum firewall pelo caminho, você conseguirá acessar o proxy também através dos outros micros da rede local, basta configurar os navegadores para usarem o proxy, fornecendo o endereço do servidor na rede local.
Caso necessário, abra a porta 3128 na configuração do firewall, para que o Squid possa receber as conexões. Um exemplo de regra manual do Iptables para abrir a porta do Squid apenas para a rede local (a interface eth0 no exemplo) é:

iptables -A INPUT -i eth0 -p tcp --dport 3128 -j ACCEPT

Referência: http://www.hardware.com.br/livros/servidores-linux/instalando-squid.html

Retirado em 26/11/2011 - 18:29

EXEMPLO CAMADA OSI

Um exemplo prático utilizando os Correios
Para entender melhor, uma pequena alegoria: um jogo, por correspondência,entre dois enxadristas, um em Teresina e outro em Goiânia5.

Os enxadristas são os usuários. O jogo em si (tabuleiro, peças e regras) é a aplicação (camada 7).

As jogadas são registradas em notação tabular (por exemplo, o movimento de um cavalo poderia ser B3C5) e escritas em folhas de papel – essa é a forma de apresentação do jogo (camada 6).
Note que não basta simplesmente colocar uma papeleta no envelope com a notação da jogada. É de bom tom escrever uma carta completa, com data, saudação e assinatura, perguntar como vai a família, o trabalho, férias, etc. para que se crie um vínculo íntimo entre os dois. Mas como enviar a jogada ao outro enxadrista?

Bem, é necessário estabelecer uma sessão (camada 5) de comunicação. Em nosso caso, a requisição da sessão é representada pelos serviços da ECT. Colocamos a carta no envelope,endereçamos (não esqueça o CEP!), selamos e colocamos na caixa de correio. Do outro lado, nosso colega vai abrir a carta e estabelecer a sessão.

A ECT é responsável pelo transporte de nossa carta (camada 4). Isso significa criar meios para que uma conexão entre os dois enxadristas seja estabelecida. Quando colocamos a carta na caixa de correio, esperamos que, de algum jeito, ela chegue às mãos do destinatário. Os mecanismos usados para tal não nos interessam. A ECT separa as cartas por região, depois por estado, depois por cidade , depois por logradouro.

Uma vez separadas, monta pacotes de cartas destinadas a cada logradouro e os envia para lá. Utiliza-se, para tal, uma rede de vias rodoviárias, ferroviárias e aeronáuticas (camada 3) e um exército de carteiros para entregar as cartas.
Os caminhões, ônibus, aviões, motocicletas e as bolsas dos carteiros são os elementos que transportam os pacotes de cartas dentro de uma mesma rede viária. Os caminhões só andam nas estradas, os aviões só voam, os carteiros só andam nas cidades.

Nenhum deles conhece os detalhes de toda a rota das cartas, sabem apenas como entregar as cartas localmente. São nossa camada 2.  Note que, caso seja preciso trocar de tipo de rede (por exemplo, sair de um avião e entrar num ônibus), nossas cartas são tratadas por funcionários dos correios que trabalham em atividades próprias da camada 3. Eles sabem mapear entre as redes.

Os pilotos dos aviões, por exemplo, não entendem nada disso. Os aviões utilizam-se do ar para sustentação e navegação. Já os caminhões trafegam pela estradas. Os carteiros andam por cada lugar que mereceriam muitas medalhas (nem o vento, nem a chuva…). O ar, as estradas e os morros são nossos meios físicos, por onde é feito o transporte de tudo o que descrevemos nas camadas superiores.

Ufa! Descrevemos pelo modelo OSI, com um exemplo não-tecnológico (tanto o correio quanto o xadrez existem há milhares de anos…), um método de transporte de mensagens entre duas aplicações. Há coisas bem interessantesa se observar nesse exemplo, o que comprova todas as teorias envolvidasno modelo de referência.
Encapsulamento: A jogada foi encapsulada na notação tabular, que foi encapsulada na carta, que por sua vez foi encapsulada em um envelope, que estabeleceu uma sessão de comunicação usando os protocolos de classificação e transporte dos Correios, que envia pacotes de cartas segundo rotas específicas, que para isso trafegou em veículos que rodavam exclusivamente dentro do meio físico específico para os quais foram feitos.
Paridade: Cada uma das camadas possui um emissor e um receptor. O pessoal de classificação e envio (camada 3) “conversa” com o mesmo pessoal da outra localidade, usando os recursos da camada inferior (o caminhão, por exemplo).
Conexão: A partir da camada quatro, vemos que todos os procedimentos precisaram que o emissor e o receptor entrem em negociação. Da camada 3 para baixo, as cartas são transportadas indiscriminadamente, sem se importar se haverá alguém lá para recebê-Ias. Não chega a ser um problema: se apenas uma das camadas estabelecer um canal de conexão permanente, as outras camadas podem trafegar” connectionless”.
Independência: As camadas são completamente independentes. A camada 4 – os setores de recebimento e entrega de cartas – não precisam saber quais rotas o pessoal da camada três – os setores de redes de transporte – utilizou. Esse pessoal trata de coordenar os diferentes meios de transporte – nossa camada 2 -, mas não se preocupa com os problemas inerentes ao transporte – qual caminhão designar,combustível, motorista, problemas com greves, sindicato… Já o motorista, além de não saber por quais outros meios de transporte as cartas trafegaram, muito menos o conteúdo de cada carta individual, preocupa-se apenas em gerenciar os problemas inerentes ao seu trabalho: seguir a rota designada pelo pessoal da camada três, operando o caminhão de acordo com as leis de trânsito, desviando de /buracos, atravessando enchentes, etc. Nenhum dos enxadristas (camada 7) sequer se incomoda em conhecer qualquer uma dessas partes do processo. Para eles, o que vale é mexer o cavalo de acordo com B3C5.

Retirado em : http://estudeccna.com.br/tutoriais/as-camadas-do-modelo-osi-analogia-dos-correios
Data:23/11/2011 - 08:55

Como é trabalhar com segurança da informação?

O evento de segurança H2HC que ocorreu no último final de semana em São Paulo chamou a atenção do público com apresentações de alto nível técnico. Para entender um pouco mais sobre o universo de segurança, entrevistei Alex Kirk, que palestrou no evento. Ele é o líder de um grupo de pesquisa da Sourcefire, principal responsável pelas atualizações das regras do Snort (um sistema de detecção de intrusão open source), assinaturas e novos métodos do antivírus Clamav. É conhecido também por ser um dos autores do livro: “Practical Intrusion Analysis: prevention and detection for the twenty-first century”.





Como funciona a equipe de pesquisa de vulnerabilidade (Vulnerability Research Team)?


Nunca há um dia de trabalho chato na VRT. Temos um fluxo constante de análise de vulnerabilidades, malware, botnets e outras ameças. Com esse estudo de campo, pensamos em formas de melhorar as detecções existentes. Dada a variedade, precisamos escolher diariamente no que focar.

Embora possa ser frustante lidar com vulnerabilidades 0-day, é muito satisfatório quando conseguimos entender e resolver o problema. Esse tipo de ocasião é denominado “fire drill”. É o momento em que todos param seus trabalhos para analisar algo novo, com uma vulnerabilidade de alto nível ou um pedaço de malware exposto. Todos nós gostamos de saber que estamos contribuindo para uma internet mais segura para os clientes Sourcefire e Snort.



Quais são as ferramentas utilizadas para analisar os novos tipos de ameaças?



Usamos uma série de ferramentas, algumas comerciais e outr as de código aberto. Para engenharia reversa, utilizamos o IDA Pro disassembler ou o WinDBG, este fornecido gratuitamente pela Microsoft. O último é extremamente útil para análise em tempo de execução. Para captura de pacotes, utilizamos o clássico Wireshark. Claro que somos grandes usuários da plataforma de virtualização da VMWare — é muito mais fácil infectar uma máquina virtual com um malware e, em seguida, clicar em “reverter” quando quiser ter a máquina na condição inicial.



Como é o processo de catalogar as ameaças?



Para as vulnerabilidades tradicionais, começamos com a pontuação CVSS (Common Vulnerability Scoring System), o padrão da indústria. Acrescentamos fatores como a disponibilidade de exploits públicos, facilidade de exploração e solicitações de clientes.



Para malware, entra uma combinação do que acreditamos ser mais persistente — ameaças que não duram mais de um dia ou dois, geralmente não valem o esforço — e pedaços de malware que classificamos como alto nível.



A verdade sobre este tipo de coisa é que há tantas ameaças aí fora que é impossível para qualquer organização dar conta de tudo. Por isso meus centros de pesquisa buscam formas genéricas de detectar malware na rede com formas de capturar diferentes tipos de malwares com uma lógica de apenas um bit de informação. Muito além da tradicional abordagem “Wack-a-mole”, que consiste em observar domínios conhecidos, faixa de IPs conhecidos e outros parâmetros.



Para fazer parte dessa equipe, qual treinamento é necessário?



Você precisa de um bom conhecimento de redes e administração de sistemas. Isto significa entender protocolos, como o TCP, HTTP, SMTP etc. Entender também permissões e procedimentos do lado de sistemas.



Precisa também no mínimo ser um programador decente, isto é, precisa entender o suficiente para ler e entender uma linguagem de programação. É importante ser capaz de automatizar tarefas, utilizando alguma linguagem script. Você ganha um bônus se conhecer Assembly x86, ser bom com expressões regulares e conhecer o Snort.

Na realidade o que mais importa é sua mente. Você precisa ser uma pessoa curiosa, desejando testar novas coisas, sempre pensando nos problemas por ângulos não triviais. É muito mais simples ensinar alguma habilidade necessária a alguém inteligente (não contratamos pessoas que não sejam). Francamente, é mais fácil ensinar os detalhes do trabalho se a pessoa é esperta. Acreditamos que esse caminho é o correto.



Na sua opinião, dado o número crescente de ameaças, qual é a forma mais ameaçadora de ataque?



Ataques do lado do cliente continuam como o maior problema. Na metade da última década, os administradores de sistemas e os grandes vendedores, como Microsoft e Oracle acordaram para a segurança. Hoje é mais difícil encontrar falhas em sistemas atualizados e com recursos de proteção. Os códigos dos sistemas também evoluiram neste sentido.



Usuários finais por sua vez, não atualizam seus sistemas, costumam visitar sites maliciosos sem pensar duas vezes e não se importam em instalar um antivírus e mantê-lo rodando. Além disso, há uma boa quantidade de falhas em navegadores e aplicativos como o Adobe Acrobat.



Como você classifica a segurança nos smartphones hoje em dia?



Os smartphones são como o velho Oeste – são poucas as regras em termos de melhores práticas de segurança e há uma tonelada de oportunidades para atores maliciosos fazerem o que bem entenderem. Quase ninguém costuma rodar antivírus em smartphones e operadoras de telecom barram atualizações de sistema, por causa dos custos de banda.



Os usuários costumam aceitar todas as permissões que as aplicações solicitam, porque acreditam que está tudo OK. Na verdade, não está. Principalmente nos Androids, ambiente em que brotam cada vez mais aplicativos com malware. Vi exemplos como um cavalo de troia de SMS na Rússia, espalhado por QRCode. Ou um mensageiro instantâneo chinês que envia seus dados para um servidor remoto.



Acredito que nos próximos anos o crescimento será exponencial e as pessoas precisam acordar para a segurança agora, não no próximo ano, porque pode ser tarde demais.



Quais projetos open source, incluindo o Snort, você recomenda para as empresas?



Obviamente somos fãs do Snort, então esta é nossa primeira recomendação. No mais, depende do que a empresa está tentando fazer. Para segurança em TI, recomendo o uso do PulledPork para gerenciar as atualizações do Snort. Gostamos do Mod_Security como firewall de aplicação web e o OpenBSD packet filter como firewall. É claro, para testes de penetração e validação de sistema de detecção de intrusão (IDS), o Metasploit.



Rodamos o sistema operacional FreeBSD na maioria de nossos sistemas internos e recentemente estamos trabalhado muito com o MongoDB, para lidar com grandes volume de dados.

Retirado de : http://info.abril.com.br/noticias/blogs/zonalivre/seguranca/como-e-trabalhar-com-seguranca-da-informacao/

Em: 11/11/2011 - 17:33

Dificuldades para migrar para o Linux

Resolvi publicar uma conversa entre pessoas que tem dificuldades de migrar de sistema operacional, abaixo a dúvida postada e mais abaixo a resposta.. é excelente.

Retirado de : http://br.answers.yahoo.com/question/index?qid=20090823161637AAA5zg9

Em :03/11/2011

Qual o sistema operacional linux mais usado no mundo e melhor em questão de desempenho, segurança, fácil?

eu preciso desta resposta para escolher um Sistema Operacional Linux para mim dedicar à minha monografia que é falando do incentivo de uso do linux

• 2 anos atrás
• Denuncie

isa

Melhor resposta - Escolhida por votação

Eu compreendo o indivíduo que declarou ter problemas em passar do Windows para o Linux. Senti o mesmo ao experimentar o Windows. Decidi experimentá-lo, depois de alguns amigos que o usam a toda a hora me dizerem que era ótimo.
Fui até ao site da Microsoft para baixá-lo mas não estava lá disponível. Fiquei frustrado porque não consegui descobrir como se baixava o mesmo. Por fim tive que perguntar a um amigo e ele disse-me que tinha de o comprar.
Fui até o carro, fui até uma loja especializada em venda de softwares diversos e pedi a um dos vendedores uma cópia do Windows. Ele perguntou-me qual, eu disse-lhe: “Quero a mais completa, por favor” e ele respondeu: “São R$ 599,00 por favor…”. Soltei um palavrão e voltei para casa de mãos abanando.
Um dos meus amigos deu-me uma cópia do Windows XP mas disse-me para não dizer nada a ninguém. Achei estranho porque faço sempre cópias do Linux para qualquer pessoa que me peça e digo sempre para passar essa cópia a qualquer outra pessoa que esteja interessada, uma vez que já precisem dela. De qualquer forma coloquei o CD no leitor e esperei que iniciasse o sistema do “Live CD”. Não funcionou. A única coisa que fazia era perguntar-me se o queria instalar. Telefonei para um dos meus amigos, para saber se estava a fazer alguma asneira, mas ele disse-me: “O XP não roda o sistema diretamente do CD”.
Decidi, então, instalá-lo. Segui as instruções que apareciam na tela mas comecei a ficar nervoso porque não perguntou nada sobre os outros sistemas operacionais. Quando instalei o Linux, ele reconheceu que tinha outros sistemas operacionais na máquina e perguntou-me se queria criar uma nova partição e instalar o Linux lá. Voltei a ligar para o meu amigo e ele disse-me que o Windows elimina qualquer outro sistema operacional que encontra, ao instalar-se.
Fiz uma cópia de segurança das minhas coisas e joguei-me de cabeça na instalação. A instalação foi bastante simples, tirando a parte em que tive que escrever umas letras e um código. Tive de ligar outra vez para o meu amigo mas ele ficou chateado e veio escrever ele próprio o código. Voltou a dizer-me para não dizer nada a ninguém (!!!).Depois de reiniciar o computador, dei corrida de olhos pelo sistema.
Fiquei chocado quando me deixou mudar as configurações do sistema sem pedir o acesso de root. O meu amigo começou a ficar um bocado irritado quando liguei outra vez para ele, mas acabou por aparecer em minha casa. Disse-me que o acesso de root era dado logo na inicialização. Tratei logo de fazer outra conta de usuário normal e passei a usá-la. Comecei a ficar confuso quando tentei fazer mudanças e o sistema, ao invés de pedir acesso de root, disse-me que tinha que fechar a sessão de utilizador normal e abrir uma sessão como administrador. Comecei, então, a perceber porque é que tantas pessoas entram sempre como root e tive um arrepio na espinha.
Bom, mas já era hora de trabalhar. Fui ao menu “Iniciar -> Programas”, para abrir uma planilha que eu precisava terminar, mas não consegui encontrar a aplicação de planilhas. O meu amigo disse-me que o Windows não trazia nenhuma aplicação dessas e que eu teria que a baixar da Internet. “Oh…”, pensei, “uma distribuição básica”. Fui ao “Adicionar/Remover Programas” do painel de controle (tal como no Linux), mas não havia lá programas para adicionar. Apenas deixava remover os programas. Não consegui encontrar o botão para adicionar aplicações. O meu amigo disse-me que eu tinha que procurar as aplicações por minha conta. Depois de muita pesquisa no Google, lá encontrei, descarreguei e instalei o OpenOffice.org.
Para dizer a verdade, diverti-me à brava com o Windows. Não entendi muito da terminologia… porque é que há um drive A, depois um C… onde é que está o drive B? Achei a distribuição demasiado básica, não inclui nenhuma aplicação que seja verdadeiramente de produtividade e torna-se muito confuso procurá-la. O meu amigo disse-me que eu precisava de software anti-vírus e anti-spyware, mas o Windows não
vinha com nada disso.
Achei-o difícil, confuso e demasiado trabalhoso para mim. Pode ser bom para uma pessoa que seja do tipo técnico, como o meu amigo, mas eu fico-me pelo Linux, obrigado.

• 2 anos atrás