Servidores Linux, Squid e BlackList.

Atualizando as blacklists

Além do filtro com base em palavras, o DansGuardian utiliza uma lista de sites proibidos, que sequer chegam a ser acessados. Por padrão, o DansGuardian vem com uma lista muito pequena e desatualizada, apenas como exemplo. Para efetivamente usar este recurso, é preciso baixar uma lista mais elaborada.

Você pode baixar uma lista longa e atualizada no http://urlblacklist.com/, o mesmo site que citei no tópico sobre o SquidGuard. As listas do UrlBlacklist são mais adequadas para uso no DansGuardian, pois incluem também listas de termos (que são usadas pelo DansGuardian para complementar o filtro estático baseado em URLs), mas ele possui a desvantagem de ser um serviço não-gratuito, onde você precisa assinar o serviço para ter acesso completo às listas.

O link completo para a versão mais recente é:
http://urlblacklist.com/cgi-bin/commercialdownload.pl?type=download&file=bigblacklist

Para instalar, basta descompactar o arquivo e mover o conteúdo para dentro da pasta “/etc/dansguardian/”, substituindo a pasta “/etc/dansguardian/blacklists” existente:

$ tar -zxvf bigblacklist.tar.gz
# cp -a –reply=yes blacklists/ /etc/dansguardian/

Depois de instalar o arquivão completo, você pode usar o script de atualização, disponível no site, para baixar atualizações de forma automática. Baixe-o em:
http://urlblacklist.com/downloads/UpdateBL

Basta ativar a permissão de execução e executá-lo. Em algumas distribuições é preciso criar a pasta “/var/lib/lrpkg/”, onde ele guarda os logs. Sem esta pasta, ele exibe um erro e não conclui a atualização.

# mkdir -p /var/lib/lrpkg/
# chmod +x UpdateBL
# ./UpdateBL

O pacote inclui várias listas diferentes, separadas por assunto. Assim como na lista do Shalla’s, as listas incluem muitos assuntos inocentes como, “cellphones”, “sports” e “childcare” (saúde infantil). Ele não é uma “blacklist” no sentido estrito da palavra, mas sim um conjunto de listas que incluem também sites sobre conteúdos diversos. A idéia aqui é que você pode bloquear todos os assuntos desejados.

Dentro de cada uma das subpastas, você encontra três arquivos: domains (sites completamente bloqueados), expressions (palavras comumente encontradas em sites de conteúdo impróprio) e urls (páginas específicas, dentro de sites permitidos). Para ativar o uso das blacklists, edite os arquivos “/etc/dansguardian/bannedsitelist” e “/etc/dansguardian/bannedurllist“, adicionando (ou descomentando) as linhas referentes às categorias que devem ser ativadas.

Para bloquear páginas de conteúdo adulto (adult), drogas (drugs), páginas pornográficas (porn) e warez, adicione (ou descomente) no arquivo “/etc/dansguardian/bannedurllist” as linhas:

.Include</etc/dansguardian/blacklists/adult/urls>
.Include</etc/dansguardian/blacklists/drugs/urls>
.Include</etc/dansguardian/blacklists/porn/urls>
.Include</etc/dansguardian/blacklists/warez/urls>

No arquivo “/etc/dansguardian/bannedsitelist” vão as linhas:

.Include</etc/dansguardian/blacklists/adult/domains>
.Include</etc/dansguardian/blacklists/drugs/domains>
.Include</etc/dansguardian/blacklists/porn/domains>
.Include</etc/dansguardian/blacklists/warez/domains>

Você pode usar também os arquivos com expressões proibidas, incluídos no pacote para reforçar a lista adicional, com os termos em português, que já ativamos anteriormente. Para isso, abra novamente o arquivo “/etc/dansguardian/bannedphraselist” e adicione as linhas:

.Include</etc/dansguardian/blacklists/adult/expressions>
.Include</etc/dansguardian/blacklists/drugs/expressions>
.Include</etc/dansguardian/blacklists/porn/expressions>
.Include</etc/dansguardian/blacklists/warez/expressions>

Faça o mesmo com outras categorias que quiser adicionar.

1 vote, 1.00 avg. rating (46% score)
Tagged , , , ,

Artigo sobre Terminal Server no win2003

Este artigo tem o objetivo de demonstrar a ativação do TS e algumas opções basicas de segurança.

 

Clique aqui para acessar o artigo

1 vote, 10.00 avg. rating (91% score)
Tagged ,

Adicionando repositório ISO no XenServer

Olá Pessoal, hoje vou fazer um breve tutorial explicando como criar um repositório ISO local no Xen Server para instalação de VM utilizando a imagem localmente, isso facilita a instalação e não necessita de acesso a internet.

Bem vamos lá:
Primeira mente autentique-se no SSH e então execute:

mkdir -p /var/opt/xen/iso_import

 

Pronto, criamos a pasta onde serão inseridas as imagens, após execute:

xe sr-create name-label=ISOs type=iso device-config:location=
/var/opt/xen/iso_import device-config:legacy_mode=true content-type=iso

Em seguida:

xe-mount-iso-sr /var/opt/xen/iso_import

Este comando irá então montar a pasta como repositório de arquivos.
Pronto, agora basta inserir as imagens (isos) dentro da pasta: /var/opt/xen/iso_import

Ao concluir todo esse procedimento, imediatamente já será inserido no Xen Center o Storange ISOs como mostra a figura abaixo:

E também no processo de instalação de um novo VM, também ira aparecer as suas imagens na lista de ISSO Image:

Pronto, agora você já pode instalar VMs utilizando a imagem do OS,
Bem é isso, em breve novos tutoriais !

1 vote, 10.00 avg. rating (91% score)
Tagged , ,

Migrando de Windows Server 2003 para Windows Server 2008 R2

Migrando de Windows Server 2003 para Windows Server 2008 R2

Temos algumas formas para fazer uma migração de um servidor executando o Windows Server 2003 R2 para Windows Server 2008 R2 com o Active Directory instalado, porém algumas recomendações:

1) Se for migrar de 2003 R2 para 2008 R2 usando o mesmo servidor (in place) só será possível se o Windows Server 2003 R2 for 64 bits, uma vez que o Windows Server 2008 R2 só vem com suporte a X64.

2) Se o Windows Server 2003 R2 for 32 bits só será possível migrar para o Windows Server 2008 R2 usando um novo servidor.

3) É importante também cuidar o idioma dos Sistemas Operacionais.

4) Recomendamos ainda verificar toda a compatibilidade de hardware e software antes de começar sua migração.

5) Não esqueça de fazer os devidos backups.

Migrando Windows Server 2003 R2 32 Bits para Windows Server 2008 ( In Place)

Neste exemplo vamos usar o DVD do Windows Server (não R2) devido a compatibilidade de arquitetura 64 e 32, mas lembramos que o processo é idêntico)

1) Insira o DVD do Windows Server 2008 no servidor com o Windows Server 2003 R2 > clique em Instalar agora

clip_image002

2) Clique em Conectar para obter as atualizações mais recentes para instalação

clip_image004

3) Selecione a versão do Windows a ser instalado > Avançar

clip_image006

4) Aceite os Termos > Avançar

clip_image008

5) Selecione Atualização

clip_image010

6) Checando a compatibilidade

clip_image012

7) Avançar

clip_image014

8) Agora é só aguardar ( Deve levar horas)

clip_image016

9) Ao finalizar a instalação, abra o console do seu Active Directory e toda sua estrutura estará OK. Verifique também as GPOs e faça os testes já conhecidos em cima do seu AD.

 

Migrando Windows Server 2003 R2 32 Bits para Windows Server 2008 R2 usando dois servidores

 

Para realizar este processo, temos alguns novos requisitos, além dos já citados no início deste tópico.

Vamos aos novos requisitos:

1) Em um servidor temos o Windows Server 2003 R2 (32 bits) e no novo servidor, o Windows Server 2008 R2 que só temos em 64 bits.

2) Temos o Active Directory instalado somente no servidor com o Windows Server 2003 R2.

3) Com o Windows Server 2008 R2 já instalado no Servidor novo, ingresse este no domínio do Windows Server 2003 R2.

No servidor Windows Server 2003 R2 execute os seguintes passos:

1) Acesse o console do Active Directory > clique com o botão direito do mouse sobre Aumentar nível funcional do domínio…

clip_image018

2) Selecione Windows Server 2003 > clique em Aumentar

clip_image020

3) Nível aumentado.

clip_image022

4) Vamos agora preparar o Domínio para receber o primeiro Domain Controller Windows Server 2003.

Insira o DVD do Windows Server 2008 R2 > no diretório Support > acesse o diretório adprep > execute os seguintes comandos:

adprep.32.exe /forestprep

clip_image024

2) Pressione C > ENTER

clip_image026

3) Processo em execução

clip_image028

4) Processo finalizado.

clip_image030

5) Execute

adprep.32.exe /domainprep

clip_image032

6) Processo finalizado.

clip_image034

7) Execute

adprep.32.exe /rodcprep

clip_image036

8) Execute

adprep.32.exe /domainprep /gpprep

Replicando o Active Directory do Windows Server 2003 R2 para o

Windows Server 2008 R2

 

Como você já deve ter percebido, todos os usuários serão autenticados pelo servidor com o Active Directory.

Esta centralização do Active Directory em um único servidor pode nos dar muito problema, uma vez que o nosso servidor do Active Directory sofra uma pane, todos os nossos usuários que autenticam nele ficarão sem acesso.

Para prevenir este possível problema você pode configurar outro servidor como Controlador de domínio adicional.

Para aplicar todo este recurso temos algumas dicas inicias:

1) Ingresse o servidor réplica do domínio principal (não esqueça que o DNS primário deverá ser o IP do seu servidor DNS local)

clip_image037

2) Servidor réplica ingressado ao domínio.

clip_image038

3) Após ingressar o Servidor réplica ao AD, ele irá aparecer no contêiner Computers.

clip_image040

4) Para iniciar a instalação do AD réplica > executar > dcpromo.exe

clip_image042

5) Marque Usar a instalação em modo avançado > Avançar

clip_image044

6) Clique em Avançar.

clip_image046

7) Como já temos uma floresta > marque Floresta existente > Adicionar um controlador de domínio a um existente > Avançar.

clip_image048

8) Automaticamente o domínio será localizado > clique em Definir e entre com as credenciais do usuário Administrador do domínio > clique em Avançar.

clip_image050

9) Clique em Avançar

clip_image052

10) Clique em Avançar

clip_image054

11) Um catálogo global é um controlador de domínio que armazena uma cópia de todos os objetos do Active Directory em uma floresta. O catálogo global armazena uma cópia completa de todos os objetos no diretório para seu domínio host e uma cópia parcial de todos os objetos para todos os outros domínios na floresta, conforme mostrado na figura a seguir.

Marque Catálogo Global > Avançar.

clip_image056

12) Selecione Replicar dados pela rede de um controlador de domínio existente > Avançar.

clip_image058

13) Selecione o Controlador de domínio > Avançar

clip_image060

14) Selecione um local para o banco de dados, log e SYSVOL > Avançar.

clip_image062

15) Informe uma senha para restauração > Avançar.

clip_image064

16) Clique em Avançar.

clip_image066

17) Replicando dados.

clip_image068

18) Clique em Concluir.

clip_image070

19) Console do Active Directory no Server 2003 (principal)

clip_image072

GPOs no Server 2003

clip_image074

20) Console do Active Directory no Server 2008 R2

clip_image076

GPOs Server 2008 R2

clip_image078

 

Instalando ferramentas de suporte no Windows Server 2003 R2

 

1) Ainda no Servidor Windows Server 2003 R2 > insira o CD de instalação do Windows Server 2003 R2 > na pasta Support\Tools > execute o arquivo SUPTOOLS.MSI para instalar algumas ferramentas.

clip_image080

2) Ferramentas já instaladas > acesse Windows Support Tools > Command Prompt

clip_image082

3) Vamos agora através do comando netdom query fsmo verificar nosso schema. Observe que todas as funções fazer parte do server2003.

clip_image084

4) No servidor Windows Server 2003 R2 vamos então transferir todas as funções mostradas na figura acima para o novo servidor executando o Windows Server 2008 R2.

 

Transferindo funções:

Vamos agora transferir as 5 regras de operações do Active Directory, essas regras também são conhecidas como FSMO Rules (Flexible Single Master Operation). Essas regras são essenciais para a saúde do AD e o bom funcionamento do AD.

Nosso objetivo é transferir essas 5 regras para o controlador de domínio Windows Server 2008 R2.

Primeiro vamos listar as 5 regras de descobrir qual os controladores de domínio tem propriedade sobre elas para isso vamos executar o comando NETDOM QUERY FSMO.

O utilitário NETDOM já foi instalado quando colocamos as ferramentas de suporte no tópico já apresentado.

Vamos agora utilizar o utilitário NTDSUTIL que é uma ferramenta de administração avançada do Active Directory para realizar a transferência.

a) Acesse Menu Iniciar > Windows Support Tools > Command Prompt

Execute os seguintes comandos:

1) ntdsutil

2) roles

3) connections

4) connect to server server2008 ( onde server2008 é o hostname do seu servidor 2008)

5) q

6) transfer schema master

7) Confirme SIM

clip_image086

b) Digite:

1) transfer PDC

2) Confirme SIM

clip_image088

c) Digite:

1) transfer domain naming master

2) Confirme SIM

clip_image090

d) Digite:

1) transfer RID master

2) Confirme SIM

clip_image092

e) Digite:

1) transfer infrastructure master

2) Confirme SIM

clip_image094

13) Execute netdom query fsmo > para verificar que foram transferidas todas as funções para o servidor Windows Server 2008 R2.

clip_image096

 

Rebaixando o AD do Windows server 2003 R2

 

1) Execute:

clip_image098

2) Avançar

clip_image100

3) Não marque a opção “Este servidor é o último controlador de domínio no domínio” > Avançar

clip_image102

4) Digite uma nova senha para o Administrador local do Servidor 2003 > Avançar

clip_image104

5) Avançar

clip_image106

6) Removendo

clip_image108

7) AD removido > Concluir.

clip_image110

8) Console do AD no Windows Server 2008 R2, observe que agora o SERVER2003 não é mais membro de Domain Controller mas de Computers.

clip_image112

clip_image114

2 votes, 10.00 avg. rating (94% score)
Tagged , , , ,

Clusters de alta disponibilidade.

Em vez de montar um único servidor com componentes redundantes, existe também a opção de usar um cluster de alta disponibilidade (chamados de “high-availability clusters” ou “failover clusters”), onde são usados dois servidores completos, onde a única função do segundo servidor é assumir a posição do primeiro em caso de falhas (modo chamado de ativo/passivo), diferente de um cluster com balanceamento de carga, onde os servidores dividem as requisições (ativo/ativo).

Existem diversas soluções para clusters de alta disponibilidade. Entre as soluções abertas, uma das mais usadas é o projeto Linux-HA (High-Availability Linux, disponível no http://www.linux-ha.org), que desenvolve o heartbeat, um daemon responsável por monitorar o status dos servidores do cluster e permitir que o segundo servidor assuma as funções do primeiro em caso de pane.

Cada um dos servidores possui pelo menos duas placas de rede, o que permite que eles sejam simultaneamente ligados à rede e ligados entre si através de um cabo cross-over ou de um switch dedicado. A conexão interna é usada pelo heartbeat para as funções de monitoramento e sincronismo dos processos, de forma que o segundo servidor possa assumir imediatamente a função do primeiro quando necessário, assumindo o endereço IP anteriormente usado por ele.

É comum também o uso de uma terceira interface de rede em cada servidor (ligada a um switch separado), destinada a oferecer uma conexão de backup com a rede. Isso permite eliminar mais um possível ponto de falha, afinal, de nada adianta ter servidores redundantes se o switch que os liga à rede parar de funcionar. :)

Em geral, o heartbeat é usado em conjunto com o Drbd (http://www.drbd.org), que assume a função de manter os HDs dos dois servidores sincronizados, como uma espécie de RAID 1 via rede. Ao usar o Drbd, o HD do segundo servidor assume o papel de unidade secundária e é atualizado em relação ao do primeiro em tempo real. Quando o primeiro servidor pára, a unidade de armazenamento do segundo servidor passa a ser usada como unidade primária. Quando o servidor principal retorna, o HD é sincronizado em relação ao secundário e só então ele reassume suas funções.

Outra opção é utilizar uma SAN (veja a seguir) para que os dois servidores compartilhem a mesma unidade de armazenamento. Nesse caso, não é necessário manter o sincronismo, já que os dados são armazenados em uma unidade comum aos dois servidores.

Como pode ver, adicionar componentes redundantes, sejam fontes, HDs ou servidores adicionais aumentam consideravelmente os custos. A principal questão é avaliar se o prejuízo de ter o servidor fora do ar por algumas horas ou dias durante as manutenções, acidentes e imprevistos em geral é maior ou menor do que o investimento necessário.

Um pequeno servidor de rede local, que atende a meia dúzia de usuários em um pequeno escritório dificilmente precisaria de redundância, mas um servidor de missão-crítica (como no caso de um banco) com certeza precisa. Cada nível de redundância adiciona um certo valor ao custo dos servidores, mas reduz em certa proporção o tempo de downtime.

A disponibilidade do servidor é genericamente medida em “noves”. Um nove indica uma disponibilidade de 90%, ou seja, uma situação em que o servidor fica fora do ar até 10% do tempo (imagine o caso de uma máquina instável, que precisa ser freqüentemente reiniciada, por exemplo), o que não é admissível na maioria das situações.

Com dois noves temos um servidor que fica disponível 99%, o que seria uma boa marca para um servidor “comum”, sem recursos de redundância. Por outro lado, uma disponibilidade de 99% significa que o servidor pode ficar fora do ar por até 7 horas e 18 minutos por mês (incluindo todas as manutenções, quedas de energia, operações de backup que tornem necessário parar os serviços e assim por diante), o que é tolerável no caso de uma rede local, ou no caso de um servidor que hospeda um site fora da área de comércio eletrônico, mas ainda não é adequado para operações de missão crítica.

Para adicionar mais um nove, atingindo 99.9% de disponibilidade (o famoso “three nines”), não é possível mais contar apenas com a sorte. É necessário começar a pensar nos possíveis pontos de falha e começar a adicionar recursos de redundância. Entram em cena as fontes redundantes, o uso de uma controladora RAID com suporte a hot-swap, uso de um nobreak com boa autonomia para todo o equipamento de rede, de forma que o servidor continue disponível mesmo durante as quedas de luz, e assim por diante. Afinal, 99.9% de disponibilidade significa que o servidor não fica fora do ar por mais de 43 minutos por mês.

No caso de servidores de missão crítica, qualquer interrupção no serviço pode representar um grande prejuízo, como no caso de instituições financeiras e grandes sites de comércio eletrônico. Passa então a fazer sentido investir no uso de um cluster de alta disponibilidade e em links redundantes, de forma a tentar atingir 99.99% de disponibilidade. Esta marca é difícil de atingir, pois significa que o servidor não deve ficar mais do que 4 minutos e meio (em média) fora do ar por mês, incluindo aí tudo o que possa dar errado.

Como sempre, não existe uma fórmula mágica para calcular o ponto ideal (é justamente por isso que existem consultores e analistas), mas é sempre prudente ter pelo menos um nível mínimo de redundância, nem que seja apenas um backup atualizado, que permita restaurar o servidor (usando outra máquina) caso alguma tragédia aconteça.

0 votes, 0.00 avg. rating (0% score)
Tagged , , ,