Página 2 de 2 PrimeiroPrimeiro 12
+ Responder ao Tópico



  1. #21

    Padrão

    Citação Postado originalmente por landrower Ver Post
    É isso mesmo amigo, libera a porta 443 para os ips que vc quer e depois bloqueia a porta 443 para qualquer outro destino.


    Abraços!
    Beleza!

    Mais vez obrigado pela sua pronta atenção.

    Abraço.

  2. #22

    Padrão

    Citação Postado originalmente por orionstation Ver Post
    Isso poderá parar os serviços de autenticação de sites como Gmail, BB, etc ...
    Você tem toda razão. Mas os usuários só navegam em meia dúzia de sites, ou seja, somente os permitidos... acho que esse sites aí ficariam resolvidos, ou não?

    Obrigado pela atenção.

    Abraço.

  3. #23

    Padrão

    Citação Postado originalmente por aprendiz_ce Ver Post
    Você tem toda razão. Mas os usuários só navegam em meia dúzia de sites, ou seja, somente os permitidos... acho que esse sites aí ficariam resolvidos, ou não?

    Obrigado pela atenção.

    Abraço.
    Se nenhum utilizar HTTPS vai estar tudo bem !

  4. #24

    Padrão

    Citação Postado originalmente por orionstation Ver Post
    Se nenhum utilizar HTTPS vai estar tudo bem !
    Foi o que eu pensei!

    Obrigado pela atenção.

  5. #25

    Padrão

    Amigo, aqui fiz um gato

    Resolvi meu problema redirecionando as requisições do IP 64.13.161.61 porta 443 para um ip qualquer

    um gato, mas funciona

  6. #26

    Padrão

    Citação Postado originalmente por phorks Ver Post
    Amigo, aqui fiz um gato

    Resolvi meu problema redirecionando as requisições do IP 64.13.161.61 porta 443 para um ip qualquer

    um gato, mas funciona
    Realmente é um "gato", e dos grandes!!! (rs)

    Não gostaria de amarras nada pelo IP e sim pelo nome de dominio... mas se a coisa apertar pro meu lado, vou usar a sua dica.

    Obrigado pela sua atenção.

    Abraço.

  7. #27

    Padrão

    Olá colegas,

    Também tive problemas com esse site https://imo.im.

    Não havia notado que outros sites bloqueados, outrora acessados por https://, faziam apenas algumas requisições de comunicação por https e o restante por http, onde o Squid acabava bloqueando.

    Fiquei pasmo ao ver a quantidade de acessos ao imo.im aqui na empresa e saí à corrida para saber o que se passa.

    Não tenho muito conhecimento em Linux e seus serviços, mas tenho que dar meus pulos aqui na empresa.

    Li esse tópico todo e achei muito interessante a abordagem, principalmente as explicações dadas de formas simples porém muito abrangente! Parabéns à todos.

    Mas quero levantar uma questão interessante e não sei se vale abrir um novo tópico para isso:

    Nas buscas anteriores que fiz para encontrar uma solução de como bloquear https em proxy transparente Squid, achei essa sugestão no link abaixo, testei, funcionou, E, me deixou com um pulga e tanto atrás da orelha:

    [FUG-BR] RES: Squid transparente e Https

    Nele, há uma sugestão de alterar, no navegador do usuário, as confiugrações de conexão com a rede, bastando dizer ao browser o IP e porta do servidor que será utilizado para conexões https.

    Fiz isso: tanto no IE como no FireFox, modifiquei a conexão de rede, comumente setada para AUTOMATICA, para manual. Para conexões HTTP as configurações de IP e porta ficaram em branco. Para conexões HTTPS coloquei o IP do servidor onde está o squid/iptables, e, porta 3128. Em seguida, coloquei o texto 'imo.im' juntamente com o arquivo .txt com as palavras bloqueadas que o squid usa. Fiz o reload e ZAZ:
    - Sites de banco acessam normalmente;
    - O site https://imo.im não abre nem que a vaca tussa;
    - Nenhuma configuração anterior foi afetada;
    - O log do squid registra os acessos às URLs dos bancos bem como as DENIED do imo.im
    - Não precisei mexer com o iptables, ou seja, no que diz respeito à squid, o iptables redireciona apenas as requisições da porta 80 para a 3128. Alías, as únicas coisas que o iptables está fazendo é compartilhar a internet (eth0) com a rede interna (eth1) e redirecionar as requisições

    Porém ficou a dúvida: Navegando dessa forma, estaria eu fazendo com que a conexão com os bancos ou outro site que use https se torne vulnerável ou menos segura?

    Ah, sim, quanto à possibilidade do usuário alterar a configuração de rede no browser, não é preocupação. As estações aqui na empresa TODAS são MS e usamos AD para autenticá-las. Há script de login que não permite execução de programas não autorizados, além de configurações padrão de desktop, inclusive o browser. No caso, as telas dessas configurações estão inoperantes para os usuários.

    Mas segue esse dúvida. Como fica a segurança da navegação quando eu faço essa alteração no borwser?

    Abraços,

  8. #28

    Padrão

    Amigo, aqui eu também utilizo proxy transparente por se tratar de uma instituição de ensino com grande movimento e vários pontos wi-fi...

    Enfim, bloqueio esses sites via iptables mesmo, da seguinte forma.

    iptables -A FORWARD -p tcp -m tcp -d imo.im -j REJECT

    100% funcional, é só voce colocar o dominio ou url que quer bloquear, independe de porta, se quiser pode colocar a porta ou bloquear também qualquer protocolo.

    Abraço,

  9. #29

    Padrão

    Galera,

    Andei lendo um pouco a documentação do squid no próprio site deles, e realmente, para proxy transparente é ilógico tratar as requisições que não sejam http. Se quisermos que https sejam tratadas, não devemos usar o proxy transparante.

    É que estamos mau habituados por causa da MS, fazer coisas com apenas um único software, onde por traz disso trata-se de um pacote deles (no caso, o ISA server). O ISA é fw E proxy. Para o linux também precisamos de um fw e de um proxy, são pacotes separados. Isso é 'comuflado na MS'.

    Dessa forma estou mais que convencido do motivo de fazer bloqueios HTTPS por iptables e não por Squid. Definitivamente este tópico pode ser encerrado bem como outros que falam sobre proxy transparente versus https.

    PORÉM, ainda não entendi o que acontece quando modifico as configurações do browser para trabalhar na situação que mencionei anteriormente.

    Abraços,

    Daniel.