Acesse o SSHD (porta 22) via regra no Firewall de borda liberado para o SSL (porta 443)

Neste post vou falar sobre uma ferramenta muito legal e que com certeza vai salvar a vida de muita gente. O sslh permite com que na mesma máquina aceite conexões HTTPS e SSH, com ele você tanto pode acessar sua aplicação na porta HTTPS quanto gerenciar seu servidor através do serviço SSH, e tudo isso apenas com a porta 443 aberta.

Imagine o seguinte, você trabalha em uma empresa onde você não gerencia o firewall de borda desta empresa, mas você tem um servidor WEB (porta 80 e 443) em produção na rede interna que é a acessada da Internet por meio de um NAT criado no firewall de borda, veja a figura abaixo:

Neste cenário temos um servidor WEB na rede interna com o IP 10.1.4.249. Como esta máquina possui um IP privado (não acessível pela Internet), então é precisso criar um NAT no Firewall para que o acesso vindo da Internet seja possível. Foi criado um NAT, onde todo o tráfego vindo da Internet com destino ao IP 200.164.100.103 será redirecionado para o IP 10.1.4.249, perceba também que só as portas 80 e 443 foram liberadas neste Firewall, com isso qualquer outra tentativa de acesso em outra porta do servidor será bloqueada pelo Firewall.

O que queremos fazer é usar a conexão liberada pelo Firewall na porta 443 para acessar minha aplicação WEB e também o serviço SSHD, que permite com que eu possa administrar meu servidor, é ai que entra o sslh. O sshl vai gerenciar toda conexão com destino a porta 443 do servidor e decidir se aquela conexão tem que ser direcionada para a aplciação (porta 443) ou para o serviço SSHD (porta 22), veja a figura abaixo:

Primeiramente vamos instalar o sslh (Debian):

#aptitude install sslh

Levando em consideração que seu servidor WEB já esta funcionando e configurado para aceitar conexões na porta 443 (SSL), certifique-se que o apache esteja escutando na porta 443 com o IP 127.0.0.1, veja figura abaixo:

 

Vamos editar o arquivo de configuração do sslh (vim /etc/default/sslh), ficando assim:

RUN=yes

DAEMON_OPTS="-u sslh -p 10.1.4.249:443 -s 127.0.0.1:22 -l 127.0.0.1:443"

Onde:

-p 10.1.4.249:443 = ip do servidor com a porta onde o sslh vai estar esperando por conexão

-s 127.0.0.1:22 = Ip e porta do serviço SSHD (neste caso local)

-l 127.0.0.1:443 = por onde as conexões SSL vão ser repassadas

Agora reinicie o serviço sslh:

#/etc/init.d/sslh restart

Veja com o comando netstat como ficou os serviços:

Pronto. Agora podemos testar.

Primeiro vamos acessar nossa aplicação WEB na porta SSL:

Como podemos ver conseguimos acessar nossa aplicação sem problema, agora vamos usar o comando ssh do linux para acessar o serviço SSHD usando o IP 200.164.100.103 e a porta 443, exatamente como usamos para acessar via browser, veja como ficou:

Agora só é entrar com a senha. Pronto você nem precisou acionar os responsáveis pelo Firewall para adicionarem uma nova porta na sua regra para acessar seu serviço SSHD.

Conhecimento é “tudo”.

Administre seu servidor com inteligência, use o Screen

Já tem um tempão que gostaria de postar algo sobre o comando screen, acho que chegou a hora. Essa ferramneta é indispensável para qualquer administrador de servidores *UNIX like*. Para ajudar a entender a importancia desse comando segue uma rápida história que acontece muito na vida de quem administra um servidor unix ou linux.

Um belo dia você é acionado pelo sobreaviso da empresa onde trabalha ou presta serviço e precisa acessar o servidor WEB de forma remota, claro você usa o SSH para isso, até ai tudo bem. No decorrer da sua análise para descobrir o que esta acontecendo com o serviço WEB você executa algum tipo de ferramente de análise e precisa de outra aba do terminal para executar o tcpdump, o que você faz? Inicia outra sessão SSH para isso, agora você tem duas sessões SSH uma em cada aba do terminal.

Depois de algum tempo sua conexão com a internet cai, você perde todas as suas conexões antes estabelecidas, inclusive a do SSH. É isso mesmo você perdeu todo seu trabalho realizado até aquele momento. Infelizmente você precisa acessar o servidor novamente e começar tudo de novo.

É ai que entra o comando screen, pense nele como se fosse aquelas abas do firefox com isso basta apenas uma conexão SSH com o servidor, e mesmo que sua internet caia não tem problema, com o screen você pode recuperar a conexão que estava usando antes de perder o acesso a internet, não perdendo nada do que estava fazendo. Vamos ao que interessa.

Instale o screen:

apt-get install screen

Um pouco do básico, para usar basta digitar screen e apertar enter:

Apartir desse momento você já esta no prompt do screen, onde você pode usar "Ctrl+A" para enviar comandos para o screen, como exercicio aperte "Ctrl+A" e depois ? para ver uma tela de ajuda mostrando os comandos que podem ser usados juntos com o "Ctrl+A": 

O comando "Ctrl+A" "c" serve para abrir outra janela dentro do screen, assim você pode rodar dois comandos ao mesmo tempo em uma conexão SSH e sem precisar colocar um dos comandos em background. Para os nossos testes não será necessário acessar nenhuma máquina de forma remota, basta abrir um terminal local. Vamos fazer um exercício para entendermos como o "Ctrl+A" "c" funciona, para esse exercicio precisamos saber que o comando "Ctrl+A" "n" serve para acessar as janelas que foram criadas. Abra um terminal, digite screen e crie mais duas janelas apertando duas vezes "Ctrl+A" "c". Agora execute o comando "top" e depois vá para a outra janela do screen com o comando "Ctrl+A" "n" e execute o comando "watch ls", execute novamente "Ctrl+A" "n" e execute o comando "netstat". Agora para você ver os comandos digitados basta ir para as suas respectivas janelas com o comando "Ctrl+A" "n". Perceba que em apenas um terminal você pode executar três comandos diferentes sem precisar colocar em background.

Você pode fechar uma das janelas criadas executando "exit" ou "Ctrl+A" "k", se você quiser apenas fechar a janela mas deixar o processo rodando execute "Ctrl+A" "d" (d=detach). Faça esse teste em uma das janelas criadas, execute "Ctrl+A" "d", agora liste as sessões do screen com o comando "screen -ls", depois de achar a sessão que você tinha feito o detach é só reestabelecer com o comando "screen -r nome-da-sessão": 

Você também pode dar nomes a sua sessão e executar o comando junto com o comando screen, neste exemplo vamos criar uma sessão dando um nome e executando o comando: 

$screen -S NomeSessao-LS ls /tmp

Agora posso executar o comando "Ctrl+A" "n" e depois listar "screen -ls" e se precisar recuperar a sessão que executei meu comando ou script "screen -r nome-da-sesao".

Dica tirada do viva o linux: 

Que tal agora compartilhar essa sessão com um amigo seu? Dá para fazer isso?

Sim! Peça para seu amigo acessar a sua máquina via ssh com o mesmo usuário que você esta logado, assim que ele logar peça para executar "screen -x", com este comando ele se conectará à mesma sessão que você esta e desta forma tudo o que você e ele fizerem serão vistos pelos dois. 

SERVIÇOS DE REDE EM SERVIDORES LINUX

Esse é um curso de nível intermediário que ministrei já alguns meses, mas vale a pena da uma olhada. Segue abaixo o que foi ministrado e logo em seguida o link para download do PDF.


DHCP

1.1. Objetivos
1.2. Introdução
1.3 Configurando um servidor DHCP
1.4 Configurando clientes DHCP
1.5 Fixar IP no DHCP

APACHE com WebDav e PHP

2.1 Objetivos
2.2 Introdução
2.3 Instalação a partir de pacotes binários
2.4 Maneiras de Iniciar, parar e reiniciar o Apache
2.5 Arquivo de configuração
2.6 Criando Domínios Virtuais
2.7 Suporte a PHP
2.8 Habilitando WebDav
2.8.1 Carregando os módulos necessários
2.8.2 Habilitando WebDav
2.9 Habilitando suporte UTF8

Servidor SSH

3.1 Objetivos
3.2 Introdução
3.3 Instalando SSHD
3.4 Usando cliente SSH

Samba

4.1 Objetivos
4.2 Introdução
4.3 Portas Utilizadas
4.4 Instalando o Samba
4.5 Entendo o básico do smb.conf
4.6 Modo de trabalho
4.7 Criando um Compartilhamento
4.8 Criando um Compartilhamento Oculto

Link: http://www.4shared.com/office/qySx22Qf/Osvaldo_-Servidores_em_Ambient.html

Bom Proveito.

Some Android App Security Problems

Someone just ripped off 21 popular free apps from the market, injected root exploits into them and republished. 50k-200k downloads combined in 4 days

Link to publishers apps here. I just randomly stumbled into one of the apps, recognized it and noticed that the publisher wasn't who it was supposed to be.

Super Guitar Solo for example is originally Guitar Solo Lite. I downloaded two of the apps and extracted the APK's, they both contain what seems to be the "rageagainstthecage" root exploit - binary contains string "CVE-2010-EASY Android local root exploit (C) 2010 by 743C". Don't know what the apps actually do, but can't be good.

I appreciate being able to publish an update to an app and the update going live instantly, but this is a bit scary. Some sort of moderation, or at least quicker reaction to malware complaints would be nice.

After some dexing and jaxing (where did I get these terms..) decompiling the code (with dex2jar and JD-GUI), the apps seem to be at least posting the IMEI and IMSI codes to http://184.105.245.17:8080/GMServer/GMServlet, which seems to be located in Fremont, CA.

The apps are also installing another embedded app (hidden as assets/sqlite.db), "DownloadProvidersManager.apk". Not sure what it does yet on top of monitoring what apps the user installs.

According to Android Police's analysis, the installed app can download and install more code.

Note, that Google has apparently started pulling at least some of the apps.

EDIT: The developer account and the apps have been removed from the market, and the links to the apps above do not work anymore. The app details are still available at Appbrain, also check this and this on Android Police, and this post by Lookout Mobile Security for a list of additional malicious apps they found on the market. Also I'd like to give credit to the devs at Teazel for helping in identifying the exploit yesterday.

EDIT2: According to Lookout Mobile Security these malicious apps were published on two additional dev accounts on top of the one I originally spotted. Appbrain links: Myournet, Kingmall2010 and we20090202. Kingmall2010's account seems to be the oldest of the bunch, according to Appbrain it started publishing around Feb 11th (so older than the four days). The other two around Feb 23rd.

Looking at the download counts for all three accounts on Appbrain. They're lagging behind the real counts, as they don't update daily, so when the Market's real download counts for Myournet on tuesday totalled at 50k-200k, Appbrain is only totalling to 10k to 35k. Even so, adding Kingmall2010's download counts from Appbrain (48k to 224k) to those I nabbed from myournet's account on Market yesterday brings the total downloads to 98k to 424k. And that estimate is probably on the low side.

Symantec on recognizing if you're infected: "If users feel that they may have installed one of these apps, they should also check com.android.providers.downloadsmanager (DownloadManageService) in the “running services“ settings of the phone"

Read more here http://www.reddit.com/r/netsec/top/?sort=top&t=all

Bom proveito.

Aplicação WEB: O que explorar?

Veja o que pode ser explorado em uma aplicação WEB:

* Client-side validation — Checks may not be replicated on the server

* Database interaction — SQL injection

* File uploading and downloading — Path traversal vulnerabilities, stored cross-site scripting

* Display of user-supplied data — Cross-site scripting

* Dynamic redirects — Redirection and header injection attacks

* Social networking features — username enumeration, stored cross-site scripting

* Login — Username enumeration, weak passwords, ability to use brute force

* Multistage login — Logic flaws

* Session state — Predictable tokens, insecure handling of tokens

* Access controls — Horizontal and vertical privilege escalation

* User impersonation functions — Privilege escalation

* Use of cleartext communications — Session hijacking, capture of credentials and other sensitive data

* Off-site links — Leakage of query string parameters in the Referer header

* Interfaces to external systems — Shortcuts in the handling of sessions and/or access controls

* Error messages — Information leakage

* E-mail interaction — E-mail and/or command injection

* Native code components or interaction — Buffer overflows

* Use of third-party application components — Known vulnerabilities

* Identifiable web server software — Common configuration weaknesses, known software bugs


Bom Proveito.

Desafio XSS filter

Muito interessante essa questão. Participe do desafio.

INGLES

An input validation mechanism designed to block cross-site scripting
attacks performs the following sequence of steps on an item of input:

1. Strip any <script> expressions that appear.
2. Truncate the input to 50 characters.
3. Remove any quotation marks within the input.
4. URL-decode the input.
5. If any items were deleted, return to step 1.

Can you bypass this validation mechanism to smuggle the following data
past it?

“><script>alert(“foo”)</script>

PORTUGUÊS

Um mecanismo de validação de entrada é projetado para bloquear um ataque de cross-site scripting realizando a seguinte seqüência de etapas quando o usuário fornece uma informação como entrada:

1. Tira as expressões <script> que aparecem.
2. Truncar a entrada em 50 caracteres.
3. Remove todas as aspas.
4. Usa o URL-decode para decodificar a entrada.
5. Se todos os itens foram excluídos, voltar ao passo 1.

Você pode burlar este mecanismo de validação para que a expressão abaixo seja aceita?

“><script>alert(“foo”)</script> 

Lançado o desafio.

Bom Proveito.

Unix Admin Horror Story

É sempre bom aprender com os erros dos outros é essa a ideia do "Unix Admin. Horror Story Summary, version 1.0". Segue abaixo uma história que chamou muito minha atenção:

Management told us to email a security notice to every user on the our
system (at that time, around 3000 users).  A certain novice administrator
on our system wanted to do it, so I instructed them to extract a list of
users from /etc/passwd, write a simple shell loop to do the job, and
throw it in the background.  Here's what they wrote (bourne shell)...

       for USER in `cat user.list`; do
          mail $USER 

Conclusão: Aprenda e Teste teste teste teste teste teste bastante

antes de executar no servidor de produção.

Bom Proveito.

New Stuff: burlando filtros web

São exatamente 23:03 de sábado, um dos meus filhos já dormiu e o outro esta jogando PS3 e eu comecei a ler a segunda edição do livro "The Web Application Hacker's Handbook_ Discovering and Exploiting Security Flaws". Ainda estou bem no comecinho do livro e resolvi testar algumas formas antigas de burlar filtros com base em blacklist mencionadas pelo livro e para a minha surpresa encontrei sites famosos onde tive sucesso em meus testes.

Nos meus testes fiz as seguintes alterações onde obtive sucesso para burlar o filtro utilizado pela aplicação:

De: SELECT
Para: SeLeCt

De: or 1=1--
Para: or 2=2--

De: alert ('xss')
Para: prompt ('xss')

Algo que chamou minha atenção no livro foi a utilização do "byte Null" (veja o meu post sobre o assunto aqui) antes de qualquer expressão bloqueada pelo filtro podendo causar a paralisação de alguns filtros.

A ideia é simples, digamos que a expressão abaixo é bloqueada pelo filtro da aplicação:
<script>alert(1)</script>

Basta adicionar o byte Null na frente.

Bom ainda não tive tempo de testar, mas vai a dica.

Bom Proveito.

Bloqueando acesso ao Facebook por roteamento

Recentemente li um post no "Viva o Linux" sobre como bloquear o acesso ao Facebook utilizando roteamento em vez de utilizar um firewall. A técnica utilizada foi a mesma que já demonstrei aqui no blog - Usando o comando ROUTE para bloquear um IP.

Neste post que li foi fornecido uma possível faixa de IP utilizado pelo Facebook para disponibilizar seus serviços e era utilizado a faixa toda para bloquear o acesso, o grande problema é que assim não se barra apenas o acesso ao www.facebook.com e sim a todos os serviços que estejam nesta faixa de IP.

Infelizmente não estou com tempo para depurar e conseguir os IPs do domínio www.facebook.com para acesso aqui do Brasil, já que acredito que os IPs são disponibilizado conforme a localização do acesso do cliente.

Os DNSs do Facebook fazem o que chamamos de round robin para os registros do domínio www.facebook.com que ficam em cache por 120 segundos, porém você não consegue esses IPs fazendo requisições para o servidor DNS do facebook - ainda não sei como isso é feito no DNS quem souber comente. Deixei um script rodando por 20 min para pegar alguns IPs, segue abaixo:

66.220.152.16
69.171.247.37
66.220.152.32
69.171.247.21

Agora é só pegar esses IPs e fazer conforme o descrito no post anterior. Lembrando que talvez esses não sejam os únicos IPs e que o facebook utilize a localização do acesso do cliente para disponibilizar seu serviço, desta forma, o acesso utilizando proxy de fora do Brasil ainda vai funcionar.

Bom Proveito.

Recuperando vários arquivos deletados - Sleuth

Em 2010 postei sobre como recuperar arquivos deletados usando a ferramenta Sleuth, confira aqui o post. O procedimento utilizado foi para recuperar alguns arquivos deletados, tornando inviável na recuperação de vários arquivos. Neste post vou compartilhar um script para recuperar vários arquivos:

#!/bin/bash
DISK=/dev/sdb1 # disco alvo
RESTOREDIR=/home/kyle/recovery # diretório para recuperar os arquivos
mkdir -p "$RESTOREDIR"
cat $1 |
while read line; do
filetype=`echo "$line" | awk {'print $1'}`
filenode=`echo "$line" | awk {'print $3'}`
filenode=${filenode%:}
filenode=${filenode%(*}
filename=`echo "$line" | cut -f 2`
echo "$filename"
if [ $filetype == "d/d" ]; then
mkdir -p "$RESTOREDIR/$filename"
else
mkdir -p "$RESTOREDIR/`dirname $filename`"
icat -f ext -r -s "$DISK" "$filenode" \
> "$RESTOREDIR/$filename"
fi
done

Para usar o script salve no diretório /usr/local/bin/ e depois mude as permissões.
$ sudo chmod a+x /usr/local/bin/restore
$ sudo /usr/local/bin/restore ~/recovery/deletados.txt

O arquivo deletados.txt tem que ser gerado com o comando:
$sudo fls -f ext -d -r -p /dev/sdb1 > ~/recovery/deletados.txt

Bom Proveito.

Squid: Considerações para um melhor desempenho

1 - Dicas antes de particionar

Quanto melhor otimizarmos o acesso a disco mais rápido será nosso proxy, adquira HD com alta velocidade (RPM) e siga essas dicas que irão ajudar no desempenho do squid:

Considere:

- Utilizar um hd somente para cache;
- Tenha muita memória RAM (o squid consome muita memória para rodar bem e ter um bom aproveitamento);
- Utilize um filtro de conteúdo externo, não use o squid para tal fim.

a) Deixe acima de 20% de espaço livre na partição contendo seu cache, o desempenho do sistema de arquivos degrada muito se o espaço utilizado excede 80%.

 b) Qual sistema de arquivo devo usar

Veja nos testes realizados no item 7 qual sistemas de arquivo teve maior desempenho na leitura e escrita no disco.

 c) O linux guarda algumas informações sobre os arquivos no sistema, como: data, hora de último acesso, ultimas modificações etc. Como o squid possui o seu próprio timestamp, de nada serve para o squid o timestamp do sistema de arquivos do SO. Para desabilitarmos essa opção na partição utilizada como cache do squid devemos utilizar o parâmetro "noatime".


2 - Utilização de RAID 0

Oferece melhor desempenho comparado a discos individuais.

Veja:

http://pt.wikipedia.org/wiki/RAID#RAID_0_Striping
http://www.youtube.com/watch?v=aIq9olTCwRA
http://www.youtube.com/watch?v=kEdV52HQ4Q8&feature=related
http://www.youtube.com/watch?v=Uwie0rJSYiE


3 - Configurando cache_mem e cache_dir

cache_mem: este parâmetro não especifica o tamanho máximo do processo do squid, ele apenas limita a quantidade de memória que o squid deve usar para os objetos.

obs: quanto maior o cache_mem maior será o uso de memória do processo do squid

cache_dir: tamanho do cache usado no disco pelo squid, digamos que você tem uma partição de 100 GB não use acima de 80 GB para o cache.

Tenha em mente:

 - O squid usa 10 MB de RAM para cada GB do cache_dir => 1 GB cache_dir = 10 MB RAM
 - Mais o valor de cache_mem
 - Um adicional de 10 a 20 MB

Levando em consideração o que foi dito vamos calcular o valor que devemos configurar no cache_(dir e mem).

Segue abaixo as configurações da máquina fictícia:

 - HD de 320 GB
 - RAM de 4 GB

DICA: pare o serviço do squid e veja quanto de memória seu sistema consome, para este tutorial vamos dizer que o sistema sem o squid consome 500 MB de memória, então vamos dar mais 500 MB de folga, ficando apenas 3 GB para ser usado pelo squid.

exemplo 1:

cache_dir = 320 GB (3200 MB de RAM)
cache_mem = 3 GB = 3000 MB

somando: 3200 + 3000 + 20 = 6220 MB de RAM

Com o exemplo acima o squid precisaria de 6 GB de RAM, então ultrapassa os 3 GB. Quanto maior for o cache_dir mais memória será necessário. Neste caso precisamos abaixar o cache_dir e o cache_mem ou comprar mais memória.


exemplo 2: vamos baixar só o cache_mem

cache_dir = 320 GB (3200 MB de RAM)
cache_mem = 2 GB = 2000 MB

somando: 3200 + 2000 + 20 = 5220 MB de RAM


exemplo 3: vamos baixar o cache_mem e dir

cache_dir = 140 GB (1400 MB de RAM)
cache_mem = 1,4 GB = 1400 MB

somando: 1400 + 1400 + 20 = 2820 MB de RAM

Neste exemplo o squid usaria 2820 MB de RAM, já que temos 3 GB podemos usar esses valores.


4 - File Desciptors

Segue abaixo alguns links que tratam sobre o problema alertado como "WARNING! Your cache is running out of filedescriptors".

http://en.wikipedia.org/wiki/File_descriptor
http://squid.sourceforge.net/hno/linux-lfd.html
http://www.cyberciti.biz/faq/squid-proxy-server-running-out-filedescriptors/
http://nixcraft.com/getting-started-tutorials/5569-squid-increasing-file-descriptor-debian.html
http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/
http://paulgoscicki.com/archives/2007/01/squid-warning-your-cache-is-running-out-of-filedescriptors/
http://goo.gl/vX8ag
http://goo.gl/vVeP9

5 - Mudando alguns parâmetros

cache_store_log none: o store.log possui informações como: arquivos removidos do cache, objetos salvos e o tempo que estão no cache. Não existe nenhuma utilidade habilitando o store.log.

maximum_object_size_in_memory: objetos maiores do que este valor não ficarão na memória, este valor deverá ser auto o suficiente para manter os objetos mais acessados na memória.

maximum_object_size: objetos maiores do que este valor não ficarão no cache do disco, se você pretende cachear arquivos grandes, como atualizações do windows, aumente este valor para 102400 (100MB).

pipeline_prefetch on: para melhorar o desempenho de requisições e fila, o Squid irá trabalhar com 2requisições paralelamente

shutdown_lifetime 15 seconds: Quando o Squid recebe um SIGTERM ou um SIGHUP, o cache é colocado em modo de"shutdown pendente" até que todos os sockets ativos sejam fechados. Qualquer clienteainda ativo depois desse período irá receber uma mensagem de timeout. Default de 30segundos

Se você não usa o proxy numa hierarquia e nem pretende usar SNMP, faça as configurações abaixo:

icp_port 0
htcp_port 0
icp_access deny all
htcp_access deny all
snmp_port 0
snmp_access deny all

6 - Politicas de troca de cache

São 4 politicas:

lru: mantem em cache os arquivos abertos recentemente
heap GDSF: otimiza o hit radio de objetos mantendo os arquivos menores e populares no cache
heap LFUDA: mantem no cache arquivos populares, independe do tamanho, otimizando o Byte HIT
heap LRU: mantem em cache arquivos abertos recentemente utilizando a politica heap

obs: quando utilizar o LFUDA aumente o maximum_object_size para 102400.

A proposta para este tutorial é utilizar um proxy que utilize menos o disco e mais a mamória RAM. Neste caso vou utilizar o heap GDSF para a memória RAM "setada" no cache_mem, veja como ficou:

memory_replacement_policy heap GDSF

É muito importante também diminuir o consumo de banda, para isso aumentamos o Byte HIT com o LFUDA:

cache_replacement_policy heap LFUDA

7 - Teste de desempenho em Sistemas de Arquivos

Para os nossos testes será usado o comando time do linux. O comando time fornece o tempo de execução de um programa, muito útil para testes de desempenho de aplicações, ele utiliza 3 medidas:

Real: o tempo total utilizado pela aplicação,desde sua execução até a finalização.

User: exibe o que o Processador usa para processar a aplicação.

Sys: o tempo gasto pelo sistema para “ajeitar” tudo no kernel mode (carregar, mover o código e iniciar a execução).

Teste 1

Criando 10000 arquivos com o comando touch:

#time for i in $(seq 10000); do touch arq$i; done

	ext3	ext4	jfs	reiserfs	xfs	zfs
real	3m11.734s	3m16.144s	3m46.433s	3m9.375s	3m18.793s	4m21.054s
user	0m34.166s	0m34.002s	0m36.474s	0m32.746s	0m32.334s	0m33.454s
sys	2m43.666s	2m50.759s	3m11.160s	2m44.238s	2m51.967s	3m14.120s

Teste 2
Rodar um find em busca de um arquivo não existente:

#time find . -name arquivo -exec ls {} \;

	ext3	ext4	jfs	reiserfs	xfs	zfs
real	0m0.081s	0m0.141s	0m0.249s	0m0.236s	0m0.249s	0m0.920s
user	0m0.016s	0m0.016s	0m0.020s	0m0.008s	0m0.036s	0m0.004s
sys	0m0.068s	0m0.060s	0m0.228s	0m0.228s	0m0.212s	0m0.288s

Teste 3
Remover os 10000 arquivos criados anteriormente:

#time rm -rf particao/

	ext3	ext4	jfs	reiserfs	xfs	zfs
real	0m2.936s	0m3.053s	0m15.308s	0m5.388s	0m12.319s	0m33.657s
user	0m0.244s	0m0.228s	0m0.172s	0m0.480s	0m0.244s	0m0.172s
sys	0m2.680s	0m2.808s	0m5.096s	0m4.808s	0m9.181s	0m11.005s

Teste 4
Criar 10000 diretórios:

#time for i in $(seq 10000); do mkdir dir$i; done

	ext3	ext4	jfs	reiserfs	xfs	zfs
real	4m16.148s	5m8.983s	4m28.631s	4m9.001s	4m29.034s	4m32.876s
user	0m37.666s	0m44.183s	0m36.114s	0m34.458s	0m41.175s	0m29.742s
sys	3m38.578s	4m29.733s	3m53.671s	3m44.546s	3m36.074s	3m33.845s

Teste 5
Rodar o comando find nos subdiretórios buscando por um arquivo não existente:

#time find . -name arquivo -exec ls {} \;

	ext3	ext4	jfs	reiserfs	xfs	zfs
real	0m1.595s	0m2.301s	0m0.947s	0m2.234s	0m1.137s	1m14.661s
user	0m0.080s	0m0.080s	0m0.040s	0m0.068s	0m0.104s	0m0.116s
sys	0m1.500s	0m1.844s	0m0.896s	0m2.144s	0m1.016s	0m26.150s

Teste 6
Remover todos os 10000 diretorios criados anteriormente:

#time rm -rf particao/

	ext3	ext4	jfs	reiserfs	xfs	zfs
real	0m6.031s	0m6.229s	0m16.875s	0m8.333s	0m18.624s	1m17.433s
user	0m0.144s	0m0.148s	0m0.220s	0m0.200s	0m0.232s	0m0.168s
sys	0m5.688s	0m5.996s	0m6.700s	0m8.041s	0m8.649s	0m25.442s

Teste7
Baixando um arquivo de 200 MB da rede local usando o wget:

#time wget http://192.168.56.101/teste.exe

	ext3	ext4	jfs	reiserfs	xfs	zfs
real	1m15.047s	1m10.764s	1m12.075s	1m15.698s	1m3.559s	1m24.298s
user	0m0.240s	0m0.116s	0m0.112s	0m0.304s	0m0.144s	0m0.184s
sys	0m24.106s	0m17.253s	0m19.397s	0m23.605s	0m14.901s	0m22.257s

Teste 8
Remover o arquivo de 200 MB

#time rm -rf teste.exe

	ext3	ext4	jfs	reiserfs	xfs	zfs
real	0m0.229s	0m0.053s	0m0.029s	0m0.079s	0m0.020s	0m1.871s
user	0m0.012s	0m0.000s	0m0.000s	0m0.000s	0m0.000s	0m0.000s
sys	0m0.148s	0m0.056s	0m0.028s	0m0.076s	0m0.020s	0m0.128s

Teste 9
Criar um arquivo de 500 MB usando o /dev/zero:

#time dd if=/dev/zero of=teste count=1050 bs=500000

	ext3	ext4	jfs	reiserfs	xfs	zfs
real	0m36.855s	0m23.009s	0m43.667s	0m36.175s	0m20.006s	0m25.787s
user	0m0.000s	0m0.000s	0m0.004s	0m0.000s	0m0.000s	0m0.008s
sys	0m21.733s	0m6.200s	0m17.081s	0m19.137s	0m4.540s	0m2.768s

Teste 10
Ler o arquivo de 500 MB criado anteriormente redirecionando para o /dev/null:

#time cat teste > /dev/null

	ext3	ext4	jfs	reiserfs	xfs	zfs
real	0m12.074s	0m6.819s	0m7.622s	0m11.822s	0m8.646s	0m32.077s
user	0m0.024s	0m0.036s	0m0.036s	0m0.016s	0m0.036s	0m0.004s
sys	0m5.064s	0m4.788s	0m4.376s	0m8.105s	0m5.112s	0m2.648s

Teste 11
Dividir o arquivo de 500 MB em vários de 10 MB usando o comando split:

#time split --bytes=10485760 teste

	ext3	ext4	jfs	reiserfs	xfs	zfs
real	0m45.588s	0m28.491s	0m28.869s	0m54.243s	0m27.239s	1m22.092s
user	0m0.032s	0m0.032s	0m0.024s	0m0.016s	0m0.036s	0m0.004s
sys	0m25.154s	0m12.437s	0m14.409s	0m37.022s	0m10.505s	0m5.720s

8 - CONCLUSÃO


Seguindo todas as dicas aqui mostradas é possível ter um squid muito robusto e que atenda na maioria dos casos, mesmo assim o Squid possui algumas limitações e problemas em termos de desempenho, foi por isso que foi criado o projeto Lusca. Recomendo a utilização do Lusca como web/Proxy cache. Para maiores informações acesse o site do projeto: http://www.lusca.org/


9 - REFERENCIA

http://wiki.squid-cache.org/SquidFaq
http://etutorials.org/Server+Administration/Squid.+The+definitive+guide/Chapter+7.+Disk+Cache+Basics/7.1+The+cache_dir+Directive/
http://www.comfsm.fm/computing/squid/FAQ.html
http://www.linofee.org/~jel/proxy/Squid/rel-notes-1_1.html#cache
http://www.visolve.com/squid/squid24s1/logfiles.php
http://webdeveloper.earthweb.com/repository/javascripts/2001/04/41291/byteconverter.htm
http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/
http://wiki.squid-cache.org/SquidFaq/WindowsUpdate

Bom proveito.