Versão Imprimível
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!
Cara,
So por curiosidade como vc bloqueou o msn???
[] Dotta :twisted:
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)
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?
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.
tb não sei como fz não.. isto chama conexão persistente
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....
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!
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
Não sou um ás em iptables mas não seria uma regra como esta no teu firewall???
--state ESTABLISHED,RELATED -j ACCEPT
Olá. Eu tenho isso aqui na empresa, mas não tenho esse controle de horário, então veja se serve para você:Citação:
Postado originalmente por gustavo_marcon
- 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.
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..Citação:
Postado originalmente por xstefanox
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
Exato! nao poderia ser mais preciso.Citação:
Postado originalmente por Super_Diaulas
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 :
Entao depois disso ele deve carregar as regras padrao, pode seria muito mais facil definir um DROP antes do RELATED,ESTABLISHED
com relação ao iptables, tudo bem
mas e com relação ao squid?
Citação:
Postado originalmente por whinston
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.
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
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?
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
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
Código :
estes logs são de um servidor que montei faz 2 dias....se o MSN está realmente utilizando o proxy, então é para aparecer logs desse tipo. No caso o MSN está bloqueado por horario, o proxy é autenticado e é barrado navegação MSN com iptables... ou seja, somente configurando o MSN para utilizar o proxy...
Irei testar ver se acontece a mesma coisa, mas aparentemente não.....
Olá, tente bloquear, quando a regra entra em vigor a range de ip's, 207.0.0.0 e veja no que da.
cria uma acl no squid
acl msnip dst 207.0.0.0
http_access deny msnip
espero que isso ajude...