Olá pessoal, nesse artigo pretendo mostrar uma forma simples e prática de bloquear o acesso ao Skype de todos os micros na rede e liberar somente computadores com acesso autorizado, evitando assim a utilização de todos para fins que não sejam de trabalho. Mãos a massa!
Olá pessoal, estou aqui com mais um artigo, espero que seja útil para todos ou quem sabe a uma grande parte dos administradores que lerem.
Existe a necessidade na empresa em se utilizar meios de comunicação onde visamos a redução de custos e usar Skype hoje em dia é fundamental pelas inúmeras vantagens que todos conhecem, só que muitos funcionários não tem a consciência de que em horário de serviço é necessário trabalhar, então cabe a nós lembrarmos-lhes disso.
Nesse artigo vou falar um pouco do SOCKS, que é um protocolo que permite que aplicações que utilizam o modelo cliente-servidor conectem-se a servidores externos através de requisições feitas ao servidor local.
Com essa configuração que eu estou postando aqui só vai funcionar se a política de firewall de vocês for bloquear tudo e ir liberando conforme a necessidade.
Exemplo do socks
Normalmente:
Micro-01 > Firewall > Rede Externa
Com o socks:
Micro-01 > Firewall > Proxy > Rede Externa
Vamos as configurações, como sempre os meus testes são feitos a partir de servidores com o Linux Fedora instalado, o que não impossibilita em nada o funcionamento em outras distribuições. Generalizando, esse artigo serve para qualquer distribuição pelo fato de estarmos compilando o source baixado do site do projeto, eu vi lá no site que no link de download ele faz referência a essas distribuições (Fedora Core 5/6, Red Hat AS.x, Solaris 8), quem for testar em outras distribuições, por favor postem o resultado aqui.
A aplicação que vou usar é o SS5. Site do projeto:
[4] Comentário enviado por m4tri_x em 19/09/2008 - 10:09h
Anderson, não sei se você chegou a ler o artigo inteiro, mais se você observar vai notar que eu enfatizei a importancia da politica do firewall ser de negação geral e liberação conforme necessidade.
:)
[5] Comentário enviado por y2h4ck em 19/09/2008 - 10:18h
Mas bloquear 443/tcp é osso né ?? Ao inves de vc ajudar os usuarios a utilizarem recursos seguros :P vc vai estar impelindo eles a usarem sempre o recurso vulneravel rs rs rs
[6] Comentário enviado por m4tri_x em 19/09/2008 - 10:23h
Não amigão, tipo, qual é a utilidade de usar a 443 diretamente da estação se podemos utilizar um proxy squid para controlar a navegação? A politica do firewall vai aplicar-se apenas as estações não ao servidor. ^^
Poderão usar a 443 normalmente através do squid.
[13] Comentário enviado por fasseabra em 23/09/2008 - 22:50h
Bom Tuto Amigo - Mas prefiro bloquear pelo Layer7 - ai Vai ;))
iptables -A FORWARD -m layer7 --l7proto skypetoskype -j DROP
iptables -A FORWARD -m layer7 --l7proto skypeout -j DROP
[15] Comentário enviado por ivancsantos em 11/05/2012 - 16:45h
Sei que o tópico é antigo, mas achei interessante e vendo os comentários gostaria de complementar com um exemplo, ressaltando sua utilidade:
Cenário:
- Em uma empresa/escritório pequeno (com poucos usuários) há um servidor rodando iptables + squid para filtro de acessos;
- Devido à necessidade de uma estrutura simples (pois não há um IT Admin) a simplicidade de um proxy transparente foi melhor opção;
- Apenas alguns usuários deverão ter acesso à internet. Os outros terão acesso apenas aos sites liberados para acesso.
Sendo assim:
- As portas altas (1024:65535) assim como as portas http e https (80 e 443) estão com DROP por segurança. As requisições http passam pelo proxy, e as https estão liberadas somente para alguns usuários, para que ninguem desautorizado consiga se logar em serviços como Facebook, por exemplo.
Surge a necessidade de utilizar o skype em todos os micros, porém nestas circunstânceas o Skype não irá funcionar, pois precisa das portas altas (1024:65535) liberadas, ou como alternativa, não tão boa diga-se de passagem pois é preferível que tenha acesso à portas udp, as portas 80 e 443. Confesso que com minha urgência em resolver o problema, eu optei por liberar as portas altas, pois desconhecia dessa solução e reconfigurar o squid para proxy autenticado não seria uma solução viável (a essa altura já estava valendo tudo! rsrs porém eu realmente precisei de uma solução rápida). Mas na próxima oportunidade irei fazer isso!