Este site não é negado pelo Proxy



  • Olá amigos,

    Descobri entre os nossos usuários aqui da empresa, que este site não está sendo barrado pelo proxy:

    http://www.caribbeankisses.com/

    Alguém pode fazer o teste aí no seu ambiente para testar. Não compreendi pq o Pfsense não consegue negar este site? Mesmo colocando ele na regra Proibidos. Os demais tudo ok, menos este.

    Obrigado,

    Ricardo Mota



  • Nenhum motivo em especial, tenta bloquear o domínio todo

    .caribbeankisses.com



  • Olha só… usando o www.caribbeankisses.com dentro da regra sites_proibidos, ele negou. Blz! Mas aqui tenho negado tudo, e somente liberado alguns sites na regra sites_liberados, pq justamente este site passou sem nenhum problema, sem estar em regra nenhuma?

    Ricardo



  • Excelente pergunta,

    Este é o momento exato para você analisar os logs e ver se tem mais algum site passando.

    Confere sua regras de firewall para ver se por exemplo um simples https antes do site não 'pula' seu proxy.



  • Caramba Marcelloc, e não é q tá passando mesmo!!!

    https://imo.im

    Este aí por exemplo passou q foi uma beleza…

    Que regra eu coloco nas Rules?

    Ricardo



  • @marcelloc:

    Excelente pergunta,

    Este é o momento exato para você analisar os logs e ver se tem mais algum site passando.

    Confere sua regras de firewall para ver se por exemplo um simples https antes do site não 'pula' seu proxy.

    'Pulou' mesmo… nem no lightsquid passou!

    https://pagseguro.uol.com.br

    Que regra eu coloco nas Rules?

    Ricardo



  • :) usuários são realmente criativos.

    O problema que você e várias pessoas passam é configurar o squid em modo transparente.

    O proxy transparente filtra somente a porta 80, enquanto a 443 fica liberada para tudo(se existir regra para isso é claro.)

    Para fechar o https, você precisa:

    • Criar uma regra na LAN bloqueando acesso a qualquer https

    • Marque o proxy em todas as estações de trabalho, desta forma o squid consegue restringir o https



  • "Marque o proxy em todas as estações de trabalho…"  Ou seja, dessa forma morre o proxy transparente?

    Ricardo



  • @ricardo.mota:

    Ou seja, dessa forma morre o proxy transparente?

    Exatamente isso ricardo.

    Se você quer auditar e restringir conexões HTTPs precisa trabalhar com proxy não transparent. Você pode até  criar uma regra que redireciona todas as conexões HTTPS saintes da sua LAN para a porta do Squid (TCP/3128), mas isso não evita o fato de que tem que deixar o proxy não transparent!

    Abraços!
    Jack



  • @ricardo.mota:

    Ou seja, dessa forma morre o proxy transparente?

    Você pode até deixar o proxy transparente para pegar os usuários criativos que vão desabilitar o proxy para tentar navegar.

    @JackL:

    Você pode até  criar uma regra que redireciona todas as conexões HTTPS saintes da sua LAN para a porta do Squid (TCP/3128).

    Esse redirect quebra a conexão https já que o squid não filtra nem quebra a criptografia da conexão.



  • @marcelloc:

    Você pode até deixar o proxy transparente para pegar os usuários criativos que vão desabilitar o proxy para tentar navegar.

    marcelloc… Você tem certeza que se manter o modo de funcionamento do Squid em "transparent", o webproxy vai conseguir trabalhar com os usuários que tem proxy marcado nas estações  ???

    Pessoalmente, eu só consegui realizar este tipo de configuração até hoje trabalhando com duas instâncias do Squid (rodando em portas diferentes)... uma atendendo aos users transparentemente e outra de modo não transparente!  ::)

    Esse redirect quebra a conexão https já que o squid não filtra nem quebra a criptografia da conexão.

    Eu tenho alguns cases em produção funcionando exatamente assim… Sem nenhum problema. Afinal, é apenas um redirect da conexão e, quando o proxy não é transparent, ele consegue trabalhar normalmente com conexões HTTPS. A única ressalva aqui, fica por conta daquelas aplicações que não admitem cache de seção (conectividade social e afins...). Mas neste caso, faz-se uma regra especial no netfilter e bola pra frente! ;)

    Abraços!
    Jack



  • Olá Pessoal,

    Vejo que a saída será usar uma GPO para usar nas configurações de proxy do IE. Dessa forma os usuários não terão acesso a mexer nessas configurações do IE.

    www.baboo.com.br/conteudo/modelos/Group-Policy-Object-Objeto-de-Politica-de-Grupo_a7671_z0.aspx

    Agradeço ao marcelloc e ao JackL, por terem clarificado as informações para mim!
    Principalmente ao marcelloc por ter me avisado sobre essa questão do proxy transparente que passa batido no caso de https. Tenha a certeza que vc contribui e muito para este forum!!!

    Voltarei para dizer se deu certo.

    Obg.

    Ricardo



  • @ricardo.mota:

    Vejo que a saída será usar uma GPO para usar nas configurações de proxy do IE. Dessa forma os usuários não terão acesso a mexer nessas configurações do IE.

    Sim Ricardo… 'automatizar' configurações e procedimentos, principalmente pra quem tem um PDC na rede, sempre é uma ótima alternativa. ;)



  • @JackL:

    marcelloc… Você tem certeza que se manter o modo de funcionamento do Squid em "transparent", o webproxy vai conseguir trabalhar com os usuários que tem proxy marcado nas estações  ???

    Pessoalmente, eu só consegui realizar este tipo de configuração até hoje trabalhando com duas instâncias do Squid (rodando em portas diferentes)... uma atendendo aos users transparentemente e outra de modo não transparente!  ::)

    O firewall faz redirect para o squid na porta definida no mesmo arquivo de configuração com transparent.

    Vou testar isso de novo hoje e te retorno.

    @JackL:

    Eu tenho alguns cases em produção funcionando exatamente assim… Sem nenhum problema. Afinal, é apenas um redirect da conexão e, quando o proxy não é transparent, ele consegue trabalhar normalmente com conexões HTTPS.

    Me referi a trasparent proxy de ssl, com o proxy marcado realmente a conversa é outra.

    em off: O dansguardian 2.12 parece ter implementado o "men-in-the-middle for admins" possibilitando o filtro de ssl. :D :o ???

    É uma questão polêmica, mas de qualquer forma vou testar.



  • Olá pessoal, só para registrar.

    As vezes as coisas não acontecem por acaso. Eu abri este post na intenção de matar uma curiosidade num único problema que apareceu. Depois das explicações dos nossos colegas de forum, percebi a gravidade do problema de usar proxy transparente, super útil porém, perigoso por não barrar o https. Pois bem, passados alguns dias, me deparei com uma ameaça real. Os usuários aqui da empresa onde trabalho usam o hotmail e MSN pessoal, e já tem uns dois dias que ando recbendo uns e-mails na conta da empresa. Acontece que os usuários estão recebendo e-mails dos seus próprios contatos que estão infectados, no corpo do e-mail consta geralmente um link para um endereço HTTPS, e é aí que mora o perigo, o bendito HTTPS está liberado geral.

    Vou fazer o teste aqui como citei, usando a GPO pelo Windows server 2008, e retirando do PFSense o proxy transparente, e retorno logo depois.

    Abraços,

    Ricardo



  • ricardo.mota,

    Obrigado pelo feedback de uma situação real.

    Vivendo a situação, o admin passa a entender a importância de ter um firewall fechado.

    att,
    Marcello Coutinho



  • Bom dia Pessoal,

    Fiz aqui a alteração que comentei, coloquei via AD as configurações de Proxy no IE. E desativei no Proxy Server a opção Transparent proxy. Bom, de certa forma funcionou, na hora que o usuário acessa por exemplo https://pagseguro.uol.com.br ele avisa que o site não é seguro e aparece o link para continuar, e ao invés de abrir o site, como estava antes de desativar o proxy transparente, aparece a mensagem do OpenDNS dizendo que não foi possível localizar o site. Daí eu fiz o bloqueio do site OpenDNS (URL: http://guide.a.id.opendns.com/?url=pagseguro.uol.com.br). De certa forma já é alguma coisa. Porém acredito que eu não precisava fazer este malabarismo, rsrsrs. Outra situação incomoda é que alguns usuários de MSN não estão conseguindo logar, uns 80% deles. Mas passado algum tempo eles voltam a logar normalmente.

    Alguém tem alguma idéia do que seja?

    Abçs

    Ricardo Mota



  • Você marcou a opção usar o mesmo servidor proxy para todos os protocolos?

    Dá uma olhada no log do squid para ver se as requisições https estão chegando nele



  • Sim, está marcado para utilizar todos os protocolos, inclusive o https.

    Agora, será que estou vendo certo o Log do squid? Onde fica? em Proxy filter SquidGuard: Log page > Filter Log ???

    Ricardo



  • Vamos tomar a pílula vermelha e ver os logs onde eles estão de fato. ;)

    abra a console do pfsense(ou habilite o ssh)

    escolha a opção 8 e em seguinda

    tail -f /var/squid/logs/access.log

    Desta forma você consegue ver os logs em tempo real.

    att,
    Marcello Coutinho



  • access.log não existe nesta pasta, alias, nada existe nesta pasta.  :o

    Ricardo



  • Vai no pacote do squid,

    Marca a opção Enabled logging e confere a pasta no campo logo abaixo.



  • Desculpa amigão, nem percebi, está em /log e não em /logs, já estou visualizando, obg.

    Ricardo Mota



  • Ricardo o problema que você está enfrentando é o mesmo que estou tendo aqui na empresa… porém no meu caso eu bloquiei o protocolo 443 e liberei uma lista de sites (ip/cidr) sendo que dá muito trabalho ter que cadastrar cada site que tenha autenticação via https.

    Como estou planejando fazer essas mudanças visando um "padrão" e uma organização a modo empresarial essa foi a melhor medida.

    http://forum.pfsense.org/index.php/topic,45551.0/topicseen.html

    Pretendo mudar muita coisa  :)



  • @marcelloc:

    Vamos tomar a pílula vermelha e ver os logs onde eles estão de fato. ;)

    abra a console do pfsense(ou habilite o ssh)

    escolha a opção 8 e em seguinda

    tail -f /var/squid/logs/access.log

    Desta forma você consegue ver os logs em tempo real.

    att,
    Marcello Coutinho

    Obrigado Marcello, Esta dica foi sensacional… estou vendo cada coisa!!! Obrigado!!!!



  • Você deve ter a porta 1863 (padrão do msn) bloqueada,sendo que a mesma a cada conexão tenta se conectar por meio de outra porta.Após umas 3 tentativas o messenger entra  :)



  • Não tenho nenhuma porta bloqueada aqui. Ontem mesmo aconteceu com o meu MSN, ele não entrou, verifiquei no proxy report e vi este endereço: evsecure-crl.verisign.com, inclui na Target categories, e na primeira tentativa o MSN entrou. Há diversos endereços que o MSN usa para fornecer o serviço de Instant Messenger. Minha lista só aumenta.

    t+

    Ricardo Mota



  • @ricardo.mota:

    Não tenho nenhuma porta bloqueada aqui. Ontem mesmo aconteceu com o meu MSN, ele não entrou, verifiquei no proxy report e vi este endereço: evsecure-crl.verisign.com, inclui na Target categories, e na primeira tentativa o MSN entrou. Há diversos endereços que o MSN usa para fornecer o serviço de Instant Messenger. Minha lista só aumenta.

    t+

    Ricardo Mota

    Se tiver mais alguma inconveniência com o Windows Live Messenger, da uma olha nesta tabela da Microsoft sempre ajuda http://support.microsoft.com/kb/2027572



  • Valeu Felipe, muito importante!!!

    obrigado,

    Ricardo


Log in to reply