Páginas

quinta-feira, 5 de novembro de 2015

Removendo Kernels No Ubuntu

Boa tarde pessoal!!!

Criei um script para remover kernels no Ubuntu de forma simplificada. Sei que já existem scripts para isso mas gosto de criar os meus e compartilhar com a comunidade. É necessário que o sistema tenha o aptitude instalado, pois ele trata melhor as dependências do que o apt. O script é bem simples, e basicamente lista os kernels instalados no sistema e te dá a escolha de removê-los:

#!/bin/bash
# Desenvolvido por Rodrigo Garcia em 05/11/2015

# Descobrir o total de kernels instalados no sistema
NUM=$(dpkg -l | grep "ii  linux-image-" | grep -v "image-generic" | grep -v "linux-image-$(uname -r)" | grep -v "extra" | awk '{ print $2 }' | wc -l)
# Contador
X=1
while [ $X -le $NUM ]
do   # Atribui o nome dos kernels um a um dentro de um array e lista
        KERNEL[$X]="$(dpkg -l | grep "ii  linux-image-" | grep -v "image-generic" | grep -v "linux-image-$(uname -r)" | grep -v "extra" | cat -n | sed -n "$(echo $X)p" | awk '{print $3}')"
        echo "$X) ${KERNEL[$X]}"
        X=$(expr $X + 1)
done
# Escolha e remoção do kernel desejado
echo -e "Escolha o kernel a ser removido: "
read Y
echo -e "Deseja realmente remover o kernel ${KERNEL[$Y]}?(s/n): "
read ANSWER
case $ANSWER in
        s)
                aptitude remove ${KERNEL[$Y]} 
        ;;
        n)
                exit
        ;;
        *)
                echo "Opção Inválida!!!"
                exit
        ;;
esac


Espero ter sido útil e até a próxima!!!

sexta-feira, 28 de agosto de 2015

Certificado Squid

Olá a todos,

Essa é uma pequena postagem apenas para ajudar aqueles que não conseguem encontrar os comandos corretos para criar um certificado para o Squid3 quando a opção de ssl-bumping (proxy https) está habilitada. Essa opção permite que sites em https também sejam filtrados, agindo o Squid como man-in-the-middle entre o cliente e o servidor, e por isso é necessário um certificado autoassinado. O Squid descriptografa a conexão, analisa o tráfego e decide se bloqueia ou não (ou alguma outra ação). 

Para ativar a opção é necessário que o Squid3 seja compilado com as opções --enable-ssl e --enable--ssl-crtd. E então colocar no squid.conf a linha:

http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB key=/etc/squid3/ssl_cert/mycert.key cert=/etc/squid3/ssl_cert/mycert.pem

Esta parte eu coloquei no final do squid.conf:

always_direct allow all
ssl_bump none localhost
acl bypass_ssl dstdomain -i "/etc/squid3/acls/bypass_ssl"
acl reverse dstdomain -i "/etc/squid3/acls/reverse"
ssl_bump none bypass_ssl
ssl_bump client-first reverse
ssl_bump server-first "nomes das acls"
ssl_bump none all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
sslcrtd_program /usr/lib/squid3/ssl_crtd -s /usr/lib/squid3/ssl_db -M 4MB
sslcrtd_children 5

Não vou explicar cada linha porque o foco aqui é a criação do certificado, então vamos a ele. Os seguintes comandos devem ser executados no servidor onde está rodando o squid:

openssl genrsa -des3 -out mycert.key 1024
openssl req -new -key mycert.key -out mycert.csr
cp mycert.key mycert.key.old
openssl rsa -in mycert.key.old -out mycert.key
openssl x509 -req -days 365 -in  mycert.csr -signkey mycert.key -out mycert.crt

cat mycert.key mycert.crt > mycert.pem

O arquivo "mycert.crt" deve ser colocado nos navegadores para permitir a filtragem https, do contrário nenhum site que utilize https funcionará.

Espero ter ajudado e até a próxima!!!

quinta-feira, 16 de julho de 2015

Mudar Autenticação Squid Para Alguns Clientes

Olá a todos,

Onde eu trabalho implantei o Squid3 com autenticação no AD, delay pools, proxy https, etc. Temos alguns logins genéricos, que são usados em máquinas compartilhadas que também estão no AD. A idéia era bloquear o acesso à Internet para esses logins genéricos para que a pessoa quando abrisse o navegador inserisse o login e senha individuais. O bloqueio funcionou, e quando abria o navegador a janela de autenticação aparecia, mas não conseguia autenticar.

Depois de muito quebrar a cabeça, cheguei à conclusão de que o navegador não conseguia autenticar porque ele simplesmente não entendia que deveria usar a autenticação básica, já que a máquina está no domínio e já tem um usuário do domínio logado nela. Foi aí que eu comecei a fuçar na Internet atrás de uma solução, e quando estava quase desistindo, consegui encontrar algo sobre http-violations.

Essa opção de compilação, habilita o Squid a violar o cabeçalho http e mudar alguns parâmetros nele. Vi algumas pessoas mudando o tipo de autenticação para o Java, pois ele também não autentica usando NTLM, testei com o meu cenário e funcionou! A dica é simples, depois do Squid compilado com a opção --enable-http-violations, basta inserir no squid.conf:

acl maquinas-compartilhadas  srcdomain       -i "/etc/squid3/acls/maquinas_compartilhadas"

reply_header_access     Proxy-Authenticate deny maquinas-compartilhadas
reply_header_replace    Proxy-Authenticate Basic realm="DOMINIO.COM.BR"
http_access     deny    rede_local logins_genericos

Com essas opções, o tipo de autenticação nas máquinas informadas (por FQDN) na ACL "maquinas-compartilhadas" vai ser mudado para o tipo "Basic", e o navegador vai conseguir autenticar tranquilamente quando a janela de autenticação for aberta. Dica simples que pode salvar bastante gente.

Até a próxima!!!

quinta-feira, 21 de maio de 2015

Utilizando a Class 4 do Squid3 Integrado ao AD

Olá a todos,

Nesses dias eu recebi a tarefa de configurar um proxy (não, esse não é um tutorial de como integrar o Squid ao AD) que entre as funcionalidades mais comuns (bloqueio de sites por domínio, palavra-chave, que fosse integrado ao AD, etc), tivesse controle de banda por login de usuário. Dentre as várias opções disponíveis, optei pelo delay_pools do Squid, e achei bastante documentação sobre sua implementação com exceção de uma coisa: A limitação por login foi implementada a partir do Squid3 (class 4) e sobre isso não tem muita documentação, aliás quase nada, apenas syntaxe de parâmetros no geral.

Depois de finalmente entender a class 4, tive dificuldade de integrar à solução que eu havia configurado. Tudo o que o site do Squid informa sobre essa classe é:

class 4 Tudo como a classe 3 de delay_pool, com um
limite adicional baseado em usuário. Isto só
tem efeito se o username foi estabelecido
previamente - forçando uma autenticação em
suas regras de http_access.

http://www.squid-cache.org/Doc/config/delay_class/

E também sobre os delay_parameters:

Para um delay_pool class 4:
delay_class pool 4
delay_parameters pool agregado rede individual usuário

http://www.squid-cache.org/Doc/config/delay_parameters/

E por mais que eu procurasse, tudo o que eu encontrava era isso. Estava quase desistindo e fazendo as limitações por IP (class 3) quando me ocorreu uma idéia: Conforme a documentação do site do Squid, a classe 4 funciona com usuários previamente autenticados nas acls, mas eu uso usuários do AD, então eu criei um http_access permitindo acesso aos grupos das velocidades e funcionou perfeitamente!!! Então a linha da acl ficou assim:

external_acl_type ad_Group ttl=60 %LOGIN /usr/lib/squid3/wbinfo_group.pl # Helper que busca grupos do AD (em versões mais recentes do Squid3 o nome do helper é ext_wbinfo_group_acl
...
acl acesso_100KB external grupo Internet-100KB

E então nas regras http_access eu fiz:

http_access allow rede_local acesso_100KB acesso_padrao !sites_proibidos !palavras_proibidas !libera_skype

Isso significa que o acesso será liberado para máquinas da rede local, que tenham usuários no grupo acesso_100KB que também estejam no grupo acesso_padrao, aos sites que não estejam nas listas sites_proibidos, palavras_proibidas e acesso_skype. Você pode criar uma linha dessa para cada limite que você quiser, daí pessoas que estão no grupo padrão podem ter várias opções de velocidades. Depois de fazer isso, então eu criei o delay_pool:

delay_pool 1 # Quantidade de pools
delay_class 1 4 # Classe do pool nº 1
delay_access 1 allow acesso_100KB # Libera acesso ao grupo acesso_100KB que já foi previamente autenticado
delay_access 1 deny # Nega acesso ao pool para todos os outros
delay_parameters 1 1 -1/-1 -1/1 102400/102400 102400/102400  # Os parâmetros do pool 1 informam que não há limite da banda total, não há limite da banda por rede, limite individual de 1 mbps e limite por username de 1 mbps

Dependendo da sua banda, você deve alterar esses parâmetros. Para mim está funcionando perfeitamente da forma que está, as páginas estão sendo bloqueadas por domínio e por palavra e a banda sendo limitada de acordo com o usuário logado. Pronto, agora na Internet já tem uma ajuda para quem quiser utilizar o delay_class 4 integrado ao AD. Espero ter ajudado, e até a próxima!!!