Página 1 de 2 12 ÚltimoÚltimo
+ Responder ao Tópico



  1. #1

    Padrão Bloqueio do MSN não está 100%

    Liberei o msn somente em determinados horários, mas com isso estou com o seguinte problema, quando o horário termina as estações continuam acessando o msn, ou seja, aqueles que estavam conectados permanecem. Mas se alguma estação tenta conectar não consegue(ou seja, funciona o bloqueio), mas não consigo barrar quem já está conectado. Como soluciono este problema?

    Obrigado!

  2. #2

    Padrão Bloqueio do MSN não está 100%

    Cara,

    So por curiosidade como vc bloqueou o msn???

    [] Dotta :twisted:

  3. #3

    Padrão Bloqueio do MSN não está 100%

    Neste caso vc vai ter que reiniciar o seu squid ou se vor via iptables deve colocar estas regras no seu crontab para poderem funcionar
    aconselho vc colocar um script blooqueando o msn nos horários que vc deseja bloquear . :@: 6)

  4. #4

    Padrão Bloqueio do MSN não está 100%

    Aproveitando o tópico, alguém sabe como faço para bloquear o msn para toda a rede e ir liberando somente para alguns usuários?

    A idéia seria a mesma do bloqueia a navegação que é feita com o proxy squid usando acl´s mas ao invez de navegação é bate papo por msn..

    Alguém tem alguma dica sobre isso?

  5. #5

    Padrão Bloqueio do MSN não está 100%

    No squid liberei somente alguns sites, o restante é bloqueado em um determinado horário é liberado todos sites.

    No squid :
    Criei uma acl para bloquear o gateway.dll, antes e depois do horário permitido, pois são dois horários no dia que são permitidos os acessos.
    No firewal :
    iptables -A FORWARD -s $Rede -p tcp --dport 1863 -j DROP
    Obs: Criei um crontab para executar essa linha.

    A questão é para os usuários que já estão conectados eles permanecem.

  6. #6
    whinston
    Visitante

    Padrão conexão persistente

    tb não sei como fz não.. isto chama conexão persistente

  7. #7
    rodrigopc-rj
    Visitante

    Padrão Bloqueio do MSN não está 100%

    Me desculpem... mas não exite esse negócio de conexão persistente...
    No TCP a comunicação é orientada a conexão, onde cada pacote enviado deve corresponder a um outro de resposta confirmando a chegada.

    Caso no meio de uma conexão o tráfego seja bloqueado, a aplicação vai parar, pois os poacotes serão enviados, serão descartados pelo firewall, não receberá a confirmação do recebimento e por isso a conexão vai falhar por time-out.
    Como os usuários que estejam conectados, após o bloqueio, continuam enviando e recebendo mensagens normalmente, está parecendo que a porta 1863/TCP seja utilizada da autenticação e verificação da base de usuários cadastrados, e o tráfego de mensagens em si, possa ser por UDP, o que faria sentido, pois é um protocolo mais rápido que o TCP e não é orientado a conexão, somente ao datagrama.
    Experimente bloquear não só o TCP mas o 1863/UDP também....

  8. #8
    rammaciel
    Visitante

    Padrão Bloqueio do MSN...

    Mesmo eu bloqueando o msn a porta 1863, continuam acessando internamente, existe outro tipo de bloqueio além da porta, parece que por http o messenger loga também. Qual o endereço que devo bloquear?


    Obrigado!

  9. #9

    Padrão ...

    Segue alguns dos "shortcuts" que os usuários usam para se conectar a rede do MSN:

    www.iloveim.com
    www.webmessenger.net
    www.msn2go.com
    www.phonefox.com

    Esses são só alguns que eu conheço, mas ainda existem alguns desconhecidos...heheheh...Você vai ouvir falar de muitos.

    Espero ter ajudado.

    Há braços

  10. #10
    Super_Diaulas
    Visitante

    Padrão Bloqueio do MSN não está 100%

    Não sou um ás em iptables mas não seria uma regra como esta no teu firewall???


    --state ESTABLISHED,RELATED -j ACCEPT

  11. #11
    flep
    Visitante

    Padrão Bloqueio do MSN não está 100%

    Citação Postado originalmente por gustavo_marcon
    Aproveitando o tópico, alguém sabe como faço para bloquear o msn para toda a rede e ir liberando somente p.ara alguns usuários?
    Olá. Eu tenho isso aqui na empresa, mas não tenho esse controle de horário, então veja se serve para você:
    - a rede toda passa pelo squid
    - tenho um arquivo chamado de "diretoria", onde estao os IPs dos micros que podem acessar todos os sites e o MSN atraves de uma acl no squid


    # neste arquivo estao os IPs um por um
    acl diretoria src "/etc/squid/diretoria"

    # neste vc poe a rede, ex: 192.168.0.0
    acl outros src "/etc/squid/outros"

    #palavras não permitidas, onde tenho varios endereços de webMSN e a palavra messenger
    acl negados_outros url_regex -i "/etc/squid/negados_outros"

    Dai depois vc vai ter as regras bloqueando ao grupo "outros" os sites de "negados_outros" e liberando tudo ao grupo "diretoria"

    e, para complementar, no meu firewall tenho isso:
    ### bloqueando MSN MESSENGER e ICQ efetivamente mas liberando para diretoria #####
    #---------------------------------------------------------------------------------
    for a in `cat /etc/squid/diretoria`; do
    $IPT -A FORWARD -p tcp -s $a -d 65.54.239.0/24 -j ACCEPT
    $IPT -A FORWARD -p tcp -s $a -d login.icq.com -j ACCEPT
    done
    $IPT -A FORWARD -p tcp -d login.icq.com -j DROP
    $IPT -A FORWARD -p tcp -d 65.54.239.0/24 -j DROP

    é isso =)

    Espero ter ajudado.

  12. #12

    Padrão Bloqueio do MSN não está 100%

    Tá aí uma questão interessante. Vamos ver o quanto nós conseguimos destrinchar o assunto.

    O amigo autor do tópico fala que ele utiliza um controle de horário para o MSN. No horário de almoço a galera tá liberada pra utilizar, mas quando o Squid teoricamente não é para permitir mais conexões com destino ao site do MSN, ele aceita.

    Agora, a pergunta que todos devem estar fazendo e que não quer calar de jeito algum: POR QUÊ?.

    Pelo o que eu andei sniffando a rede aqui, descobri que quando uma pessoa faz uma requisição para se conectar ao MSN por HTTP (Passando pelo Squid), ele faz uma requisição à um determinado endereço, aquele famosinho que tem a palavra-chave gateway.dll no meio e que é bloqueado na lista de palavras negadas do Squid. Depois disso não é feita nenhuma outra requisição, pois uma conexão TCP/IP é estabelecida. O tráfego que acontece não deve ser HTTP, por isso ele não rola por cima do Squid.

    A solução do problema seria, de fato, reiniciar o serviço do Squid, mas mesmo assim os usuários não cairiam do MSN por já estarem conectados e utilizando o NAT do Kernel.

    De qualquer forma, é uma sugestão de estudo, pois é um assunto interessante esse e eu estou realmente pensando em como fazer esse controle.


    Um abraço!

  13. #13
    whinston
    Visitante

    Padrão será?

    Citação Postado originalmente por xstefanox
    Tá aí uma questão interessante. Vamos ver o quanto nós conseguimos destrinchar o assunto.

    O amigo autor do tópico fala que ele utiliza um controle de horário para o MSN. No horário de almoço a galera tá liberada pra utilizar, mas quando o Squid teoricamente não é para permitir mais conexões com destino ao site do MSN, ele aceita.

    Agora, a pergunta que todos devem estar fazendo e que não quer calar de jeito algum: POR QUÊ?.

    Pelo o que eu andei sniffando a rede aqui, descobri que quando uma pessoa faz uma requisição para se conectar ao MSN por HTTP (Passando pelo Squid), ele faz uma requisição à um determinado endereço, aquele famosinho que tem a palavra-chave gateway.dll no meio e que é bloqueado na lista de palavras negadas do Squid. Depois disso não é feita nenhuma outra requisição, pois uma conexão TCP/IP é estabelecida. O tráfego que acontece não deve ser HTTP, por isso ele não rola por cima do Squid.

    A solução do problema seria, de fato, reiniciar o serviço do Squid, mas mesmo assim os usuários não cairiam do MSN por já estarem conectados e utilizando o NAT do Kernel.

    De qualquer forma, é uma sugestão de estudo, pois é um assunto interessante esse e eu estou realmente pensando em como fazer esse controle.


    Um abraço!
    suas colocações foram corretas stefano, mas olha soh..
    tenho cliente que nao tem NAT, pra nao pegar spyware e tal.
    como eles tem mail server local, nao tem necessidade de usar outras portas, entao por isto não tem NAT, apenas o squid.
    o problema acontece da mesma forma.
    axo que eh pq na hora que o cara de autentica, ou na hora da primeira conexao, o squid ve la: bom, hora do rango, o cara pode, libera. os outros pacotes vao tudo no "vacuo", nao precisando mais se autenticar, axo que eh ae que tao problema.
    neste caso, uma solucao seria realmente agendar pro squid reiniciar a cada 300min. por exemplo

  14. #14
    felco
    Visitante

    Padrão Bloqueio do MSN não está 100%

    Citação Postado originalmente por Super_Diaulas
    Não sou um ás em iptables mas não seria uma regra como esta no teu firewall???


    --state ESTABLISHED,RELATED -j ACCEPT
    Exato! nao poderia ser mais preciso.

    Se voce tiver uma regra dessa o -j DROP deve vir antes dela, isso porque o drop vindo depois, nao adianta porque o pacote sera beneficiado por pertecer a uma conexao estabelecida previamente.

    Voce pode fazer o seguinte, porem isso derruba todas as conexoes :twisted:
    No momento que ele vai carregar as regras para bloquear voce faz um DROP geral momentaneo:

    Código :
    iptables -P INPUT DROP
    iptables -P FORWARD DROP
    iptables -P OUTPUT DROP
    iptables -X
    iptables -F

    Entao depois disso ele deve carregar as regras padrao, pode seria muito mais facil definir um DROP antes do RELATED,ESTABLISHED

  15. #15
    whinston
    Visitante

    Padrão ao felco

    com relação ao iptables, tudo bem
    mas e com relação ao squid?

  16. #16
    Super_Diaulas
    Visitante

    Padrão Re: ao felco

    Citação Postado originalmente por whinston
    com relação ao iptables, tudo bem
    mas e com relação ao squid?

    Se o tráfego não for http ? como o xstefanox disse?

    Eu tenho DROP para tudo, o que eu preciso é jogar apenas 3 regras do iptables que a pessoa conecta, funciona para qualquer versão de msn.

  17. #17
    flep
    Visitante

    Padrão Bloqueio do MSN não está 100%

    Pessoal, estive olhando os logs do squid, e percebi que gateway.dll é acessado seguidamente, ou seja, ele que mantem a conexão e o envio/recebimento de mensagens.
    Notei também que ele sempre roda em cima do IP 207.46.3.0/24, ou seja, creio que se vc colocar na sua cron para ativar um bloqueio a esse IP no seu firewall no horario em que o MSN não pode ser utilizado, o MSN vai cair por timeout.

    Alguem aí pode testar?
    []s
    flep

  18. #18
    felco
    Visitante

    Padrão Bloqueio do MSN não está 100%

    Hummmmmmm

    Me parece que o MSN no caso dele nao esta saindo pelo Squid, veja bem me parece, porque acaso fosse isso a acl deveria bloquear.

    Pra gente saber aonde esta o furo vamos ter que ver o ruleset dele... e se nao tiver um furo pra saida do MSN pela porta normal, agente parte pro Squid.

    Pensando aqui deve ter um furo no ruleset mesmo, porque acaso o MSN estivesse saindo pelo Squid o Squid bloquearia atravez de ACLs, dificilmente se cria(é realmente possivel?) ACLs com furos, partindo do ponto que o uso da porta 80 pelo MSN é a ultima opcao, provavelmente ele deve estar saindo pela porta default usando algum furo no ruleset é sendo esse o caso qualquer ACL no Squid é inutil, ja que o Squid trata(por padrão) apenas o trafego da porta 80.

    Cado o cara que abriu o topico?

  19. #19
    flep
    Visitante

    Padrão Bloqueio do MSN não está 100%

    Psé, a gente começou a dar varias opções e o cara que abriu o topico sumiu hehehehehe

    É.. teoricamente se vc tem um FW setando a porta 80 pra ir pela 3128 e nao deixando nada direto, entao o MSN deve passar pelo squid.

    AQUI no meu squid sempre aparece requisição do gateway.dll enquanto conectado no MSN.

    []s
    flep

  20. #20
    Super_Diaulas
    Visitante

    Padrão Bloqueio do MSN não está 100%

    talvez gateway.dll seja apenas um arquivo contendo novos ips, para manter atualizada a lista de conexão do desgraçado, e vem disfarçado numa dll