—————————-

Para fazer cache do windows update para seu squid cache, adicione as seguintes linhas ao seu squid.conf.

##### Cache do Windows Update #####
refresh_pattern au.download.windowsupdate.com/.*.(cab|exe|msi) 10080 100% 43200 reload-into-ims
refresh_pattern download.microsoft.com/.*.(cab|exe|msi) 10080 100% 43200 reload-into-ims
refresh_pattern msgruser.dlservice.microsoft.com/.*.(cab|exe|msi) 10080 100% 43200 reload-into-ims
refresh_pattern windowsupdate.com/.*.(cab|exe|msi) 10080 100% 43200 reload-into-ims
refresh_pattern www.microsoft.com/.*.(cab|exe|msi) 10080 100% 43200 reload-into-ims
################################

A Microsoft na busca de reduzir o tráfego web utiliza-se geralmente de HTTP Range-Offsets’ (Vulgo Range parcial de arquivos). Para isso precisamos alterar no squid as seguintes configurações.

* maximum_object_size
Essa variável define o tamanho dos objetos em cache. Como alguns updates são grandes (ou mesmos outros arquivos a serem armazenados em cache) precisamos setar essa variável num valor razoável. Recomendo valores acima de 100 MB.

Exemplo
maximum_object_size 100 MB

* quick_abort_min
Esta variável define o quanto de uma requisição o squid continuará a baixar mesmo que essa requisição tenha sido abortada. Seu valor padrão é de 16 KB.
Para que os updates do Windows sejam baixados na primeira vez que um cliente faz um update deve-se alterar o valor da variável para -1.

Exemplo
quick_abort_min -1

* range_offset_limit
Por último deve-se alterar a variável range_offset_limit. Essa variável define o quanto do arquivo deve ser buscado antecipadamente em requisições parciais de arquivo. Alterando-se essa variável para -1 (Nenhuma) o arquivo será sempre requisitado do ínicio independente da solicitação do cliente.

Exemplo
range_offset_limit -1

- Dica crucial -
É importante saber que a alteração do range_offset_limit para o valor -1 aumenta consideravelmente o consumo de banda. E por isso é necessário fazer uma alteração que não está descrita no FAQ do site do SQUID. (http://wiki.squid-cache.org/SquidFaq/WindowsUpdate)

A alteração consiste em definir os domínios os quais o range_offset_limit é alterado. Por sorte essa variável permite a utilização em conjunto com acl’s. Então basta definir via acl os endereços onde ficam os updates da microsoft tal como no refresh_pattern.

Exemplo.
acl windowsupdate dstdomain au.download.windowsupdate.com
acl windowsupdate dstdomain download.microsoft.com
acl windowsupdate dstdomain msgruser.dlservice.microsoft.com
acl windowsupdate dstdomain windowsupdate.com
acl windowsupdate dstdomain microsoft.com

E em seguida alterado o range_offset_limit.

Exemplo
range_offset_limit -1 windowsupdate

Para os mais afoitos, segue a configuração a ser feita completa.

———— Copie e cole ———————

##### Cache do Windows Update #####
refresh_pattern au.download.windowsupdate.com/.*.(cab|exe|msi) 10080 100% 43200 reload-into-ims
refresh_pattern download.microsoft.com/.*.(cab|exe|msi) 10080 100% 43200 reload-into-ims
refresh_pattern msgruser.dlservice.microsoft.com/.*.(cab|exe|msi) 10080 100% 43200 reload-into-ims
refresh_pattern windowsupdate.com/.*.(cab|exe|msi) 10080 100% 43200 reload-into-ims
refresh_pattern microsoft.com/.*.(cab|exe|msi) 10080 100% 43200 reload-into-ims
################################

maximum_object_size 50 MB
quick_abort_min -1

##### ACL Dominios do Windows Update #####
acl windowsupdate dstdomain au.download.windowsupdate.com
acl windowsupdate dstdomain download.microsoft.com
acl windowsupdate dstdomain msgruser.dlservice.microsoft.com
acl windowsupdate dstdomain windowsupdate.com
acl windowsupdate dstdomain microsoft.com
################################

range_offset_limit -1 windowsupdate
range_offset_limit 0

————————————————

A linha de “range_offset_limit 0″ é opcional isto porque o squid procura de cima para baixo em sua configuração pelas regras e caso o domínio acessado não esteja na ACL o valor padrão é adotado para a variável.

Como sempre gosto de mostrar segue abaixo 3 linhas do access.log do squid fazendo cache do Windows Update sem nenhuma dessas ferramentas de redirecionamento.

1282048807.733     26 192.168.3.28 TCP_HIT/206 19838 GET http://au.download.windowsupdate.com/msdownload/update/software/defu/2010/08/mpas-d_bd1_6dea7c0ba060e4a15430e4e421463125d691045f.exe – NONE/- application/octet-stream
1282048808.975    223 192.168.3.28 TCP_HIT/206 93543 GET http://au.download.windowsupdate.com/msdownload/update/software/defu/2010/08/mpas-d_bd1_6dea7c0ba060e4a15430e4e421463125d691045f.exe – NONE/- application/octet-stream
1282048809.907    109 192.168.3.28 TCP_HIT/206 67717 GET http://au.download.windowsupdate.com/msdownload/update/software/defu/2010/08/mpas-d_bd1_6dea7c0ba060e4a15430e4e421463125d691045f.exe – NONE/- application/octet-stream

Fontes pesquisadas:
http://wiki.squid-cache.org/SquidFaq/WindowsUpdate
http://www.squid-cache.org/Doc/config/quick_abort_min/
http://www.squid-cache.org/Doc/config/range_offset_limit/

Interface agradável, programas já instalados preenchem plenamente as necessidades básicas e a aquela antiga dificuldade com drivers cada vez menor.

Até mesmo a placa de vídeo i965 (x3100) foi reconhecida corretamente e com o Compiz ativado. Detalhe a parte, tem uma performance horrível, mas pelo menos funciona.

Infelizmente como nem tudo sao flores, fui mais um dos contemplados a possuir uma placa Wireless Atheros AR5007EG ou como o linux a reconhece “AR5001″. Final das contas, meu wireless nao funcionava.

Comecei entao a ler a saida do  “dmesg” e encontrei uma linha falando que o ath_hal era incompativel com minha placa, entao por curiosidade descarreguei o modulo e voilá meu wireless funcionou!

Para fazer com que a alteracao fique permanente em seu computador siga o seguinte passo.

# echo “blacklist ath_hal” >> /etc/modprobe.d/blacklist-ath_pci.conf

Reinicie o seu computador e verifique se sua interface wireless detectou alguma rede sem fio.

Lembrando que a dica acima objetiva a utilizar o wireless AR5001 com o driver nativo do Ubuntu. Para os mais experientes, fique ciente que o driver funciona perfeitamente com o Aircrack-ng.

Utilizando-se de brute-force obtiveram senhas de emails no servidor e com isso spammers dispararam emails através de uma conta válida autenticando-se via SASL. O remetente dos email (mail from) eram forjado com outros endereços.

Ele me perguntou se eu sabia como bloquear emails forjados e comecei a pesquisar.

A princípio pensei em desenvolver filtro de conteúdo (content filter), abrir as mensagens com um sed e comparar o SASL com o Mail From da mensagem. Mas logo depois resolvi pesquisar um pouco mais no site do Postfix.

Grata a surpresa o Postfix já possui essa proteção, foi então que encontrei o seguinte parâmetro:

reject_sender_login_mismatch
Reject the request when $smtpd_sender_login_maps specifies an owner for the MAIL FROM address, but the client is not (SASL) logged in as that MAIL FROM address owner; or when the client is (SASL) logged in, but the client login name doesn’t own the MAIL FROM address according to $smtpd_sender_login_maps.

Sabido que era a solução do problema, configurei o postfix da seguinte maneira.

Editei o arquivo /etc/postfix/main.cf e adicionei as seguintes linhas.

———————————————————————————————

smtpd_sender_login_maps = proxy:mysql:/etc/postfix/sql/mysql_virtual_sender_login_maps.cf

proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps $smtpd_sender_login_maps

smtpd_sender_restrictions = reject_sender_login_mismatch

———————————————————————————————

Em seguida foi criado o arquivo referenciado no main.cf do postfix (/etc/postfix/sql/mysql_virtual_sender_login_maps.cf) com o seguinte conteúdo.

———————————————————————————————

user = postfixusr
password = postfixpassword
hosts = localhost
dbname = postfix
query = SELECT username FROM mailbox WHERE username=’%s’ AND active = ’1′

———————————————————————————————
Lembrando que os campos da tabela podem estar diferentes, o exemplo segue conforme as tabelas utilizadas pelo postfixadmin (www.postfixadmin.org)

Se você deseja aplicar o bloqueio de emails forjados somente para usuários autenticados, altere a restrição de envio com o seguinte parâmetro “reject_authenticated_sender_login_mismatch”

Então reinicia-se o postfix (#postfix reload), e está pronto o bloqueio da saída de emails forjados do servidor.

Fonte: http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch

Outros parâmetros que merecem atenção no filtro de emails indesejados.

reject_sender_login_mismatch, reject_unauthenticated_sender_login_mismatch, reject_unknown_sender_domain, reject_unlisted_sender

Para quem não conhece, o RTLAPCONF é um utilitário que fornece informações de dispositivos wireless com chipset Realtek.
Ele tem como princípio auxiliar mas muitas das vezes é uma dor de cabeça pra administradores de rede.

Para bloquear, basta filtrar a porta de destino 21212/udp.

Qualidade, Funcionalidade, Praticidade e Preço.

Um recurso importante mas que até pouco tempo era ausente no equipamento era o suporte a Vlan, a partir da versão 3.1 (07/23/2008 AirOS firewall/DFS) do AirOS o suporte foi disponibilizado. Entretanto é necessário editar as configurações manualmente através do terminal. Abaixo explico como proceder para colocar ativa uma Vlan no Nanostation.

Estarei explicando como fazer a Vlan em modo Bridge, mas caso queira fazer em modo router só muda a interface a adicionar a Vlan.

Estando com sua conexão ativa até a Nanostation, logue via terminal.

Altere o arquivo /etc/persistent/rc.poststart e insira a Vlan.

# vconfig add br0 (ID-Vlan)

Se quiser colocar um IP na Vlan faça:

# ifconfig br0.(ID-Vlan) 192.168.1.1 netmask 255.255.255.0

Lembrando que (ID-Vlan) é o número de sua Vlan.

Altere a permissão do arquivo para execução.

# chmod +x /etc/persistent/rc.poststart

Por fim, basta salvar e reiniciar sua NanoStation

# cfgmtd -w -p /etc/ 
# reboot

Observação importante:
As alterações no diretório não devem exceder 64k de tamanho.

Vamos do início. Recentemente instalei um servidor de email para um cliente e resolvi que dessa vez iria fazer algo diferente.

Através de discussões na internet ví relatos que o Dovecot era um Servidor POP/IMAP mais rápido que o Courier e também mais estável, além de sua premissa básica de prezar pela segurança.

Mesmo nunca tendo problemas com a estabilidade do Courier resolvi testar o até então desconhecido Dovecot.

Antes de implementar comecei a pesquisar a respeito e planejar a instalação. Grata surpresa ao ler o site oficial que o Dovecot já possui integrado um SASL (esqueça o Cyrus SASL, SASL é na verdade uma abrevitatura de Simple Authentication and Security Layer). Ví que a conversão das contas do Courier seria simples pois o site do Dovecot possui o script pronto.

Outra coisa que me chamou atenção no Dovecot é a facilidade de se instalar Plugins, Quota, Sieve, tudo pode ser facilmente integrado.

Uma idéia fixa na minha cabeça seria que o servidor seria instalado totalmente out-of-box (pacotes padrão), quer dizer, eu não iria compilar nada. Isso porque muitas vezes outro técnico da empresa vai dar manutenção no servidor e um apt-get upgrade pode sobrescrever o que não deve, ou mesmo que se utilize apt preferênces o pacote iria ficar desatualizado.

Então ficou assim instalado:

- Postfix TLS
- Dovecot POP/IMAP TLS
- Dovecot SASL
- Clamav com Clamav-Filter
- Greylist
- Spamassassin

Talvez se perguntem onde está o filtro de antivirus, mas não utilizo Amavis e nem MailScanner, a uns 4 anos testei o Clamav-Filter, que é um filtro de conteúdo para Postfix e pelo menos na época não tinha comparação, era umas 10x mais rápido que o Amavis.

Se quiser saber como instalar, abaixo está o endereço do site do desenvolvedor do script. A propósito, a página dele possui bons artigos de Postfix.
http://www.unitednerds.org/thefallen/docs/index.php?area=Postfix&tuto=Clamav-gsoares

Agora que já contei a história, vamos a solução. Depois de tudo instalado, resolvi que nesse servidor utilizaria a marcação do Spamassassin para mover as mensagens marcadas como Spam diretamente para a pasta Spam na caixa do usuário, e foi quando começou a luta.

Procurei a respeito, e encontrei alguns artigos de como utilizar o Procmail para o propósito, mas somente depois de quebrar a cabeça algum tempo descobri que o Procmail só faz o delivery para contas locais e o servidor foi instalado com suporte a domínios virtuais.

Então fui atrás de ativar o Maildrop para esse propósito.

Como utilizo Debian, instalar o Maildrop é moleza, um simples apt-get install maildrop é suficiente, e, resta somente ativá-lo no Postfix.

Conforme explicação do site oficial (http://www.postfix.org/MAILDROP_README.html)
Postfix pode ser configurado para a entrega de mensagens diretamente ao maildrop, sem utilizar o agente local de entrega como intermediário. Isso significa que você não terá disponível os aliases (/etc/aliases) ou o arquivo .forward
Tipicamente utilizado onde os usuários não possuem contas locais no sistema.

Primeiro vamos alterar o arquivo main.cf do Postfix, adicione ou altere conforme o caso, as seguintes linhas:

###################### Maildrop ######################
virtual_transport = maildrop
maildrop_destination_recipient_limit = 1
######################################################

Em seguida alteramos o arquivo master.cf, adicione as linhas abaixo:

###################### Maildrop ######################
maildrop   unix -       n       n       -       -       pipe
   flags=DRhu user=vmail argv=/usr/bin/maildrop -d vmail ${nexthop} ${user} ${extension}
######################################################

Detalhe, se você seguir os passos conforme o site oficial o maildrop não vai funcionar, isso claro, para domínios virtuais. As linhas conforme o site oficial são para usuários que possuem contas locais no sistema.
Repare que na segunda linha está especificado o usuário vmail. Esse usuário não deve ser o mesmo utilizado pelo postfix.

Agora que vem o script que você os emails, crie o arquivo /etc/maildroprc com o conteúdo a seguir:

################# /etc/maildroprc ####################
SHELL=/bin/bash

DOMAIN=tolower(“$1″)
USER=tolower(“$2″)
EXTENSION=tolower(“$3″)
USERMAILDIR=”/var/mail/virtual/$DOMAIN/$USER”

if (/^X-Spam-Flag: *YES/)
 {
     exception {
         to “$USERMAILDIR/.Spam/”
     }
 }
######################################################

Altere as permissões do arquivo para o usuário vmail, esse usuário deverá ter permissão de escrita no diretório de email dos usuários.

A ideia do arquivo é a seguinte, primeiro são definidos as variáveis que foram recebidas pelo Postfix, logo em seguida através do uso de expressão regular move-se qualquer mensagem com o header “X-Spam-Flag: *YES” para o diretório escolhido.

Por fim, para que as alterações façam efeito, reinicie o Postfix.
# postfix reload

Pronto, seu Postfix utilizando-se do Maildrop encaminhará as mensagens marcadas como Spam para a pasta definida.

Se tiver alguma dúvida, não se esqueça de postar os logs do erro, se for o caso.

Como sempre utilizei diskd, procurei pesquisar sobre o assunto e encontrei a informação ( http://wiki.squid-cache.org/Features/DiskDaemon ) que o diskd agilizava o acesso a I/O de disco nas versões 2.4 do kernel, mas a partir da versão 2.6 o aufs se apresentava um sistema mais rápido para a mesma função, o diskd é recomendado atualmente para as variações BSD.

Modern Linux systems the Disk Daemon has been trumped by extremely fast AUFS. diskd is still recommended for BSD variants. However, we may have found an implementation bug in squid which was hobbling AUFS on BSD

Portanto, afim de corrigir a informação de meu post anterior http://www.linuxadm.com.br/2008/02/08/otimizando-o-squid-versao-2008 prefira utilizar o AUFS para o seu cache_dir.

Após a troca, utilizando-se do squid-graph percebi uma considerável diferença nos tempos de resposta de cache_hit e cache_miss

Muitos usuários se restringem a alterar o ip_forward, talvez porque desconhecem a imensidão do kernel linux, mas os curiosos e escovadores de bit se deliciariam num simples sysctl.

Ao apresentar algum problema, o linux apresenta um kernel panic e fica travado nessa tela, não seria mais simples se isso pudesse ser resolvido sem a intervenção do usuário e/ou administrador?

Alterando o parametro kernel.panic você pode definir um tempo para reboot do servidor após o crash.

# When the kernel panics, automatically reboot in 3 seconds
kernel.panic = 3

Para alterar esse valor em tempo de execução utilize “sysctl -w kernel.panic=60″ ou “echo 60 > /proc/sys/kernel/panic” onde o valor numérico refere-se ao tempo até o reboot do linux.

Ano Novo, site novo.

Fiquei muito tempo sem postar, mas ânimo renovado para esse ano que se inicia.

Espero poder compartilharmos aqui mais experiências do Cotidiano da administração de redes.

Um abraço a todos.

01:00.0 Ethernet controller: Hangzhou Silan Microelectronics Co., Ltd. RTL8139D [Realtek] PCI 10/100BaseTX ethernet adaptor (rev 01)

Visto que o Linux não reconheceu a placa como Realtek, procurei por Hangzhou Silan, no google, e encontrei a verdade sobre a placa. O chipset em questão é falso, e para ser instalado deve ser compilado o driver correto (SC92031) já disponível nos ultimos kernels.