[GTER] Bloqueio de portas

Elias Andrade esan_br at yahoo.com.br
Tue Mar 21 16:38:12 -03 2017


	Realmente, diz de maneira muito clara na minha interpretação: Basta
por no contrato SCM o motivo da filtragem.

====== CAPÍTULO I DISPOSIÇÕES PRELIMINARES =========

Art. 2o A disciplina do uso da internet no Brasil tem como fundamento
o respeito à liberdade de expressão, bem como:
V - preservação da estabilidade, segurança e funcionalidade da rede,
por meio de medidas técnicas compatíveis com os padrões internacionais
e pelo estímulo ao uso de boas práticas;

===== Seção I Da Neutralidade de Rede ===
Art. 9o O
III - informar previamente de modo transparente, claro e
suficientemente descritivo aos seus usuários sobre as práticas de
gerenciamento e mitigação de tráfego adotadas, inclusive as
relacionadas à segurança da rede; e

IV - oferecer serviços em condições comerciais não discriminatórias e
abster-se de praticar condutas anticoncorrenciais.

§ 3o Na provisão de conexão à internet, onerosa ou gratuita, bem como
na transmissão, comutação ou roteamento, é vedado bloquear, monitorar,
filtrar ou analisar o conteúdo dos pacotes de dados, respeitado o
disposto neste artigo.

> *Ou seja*, em relação ao Parágrafo Terceiro aí de cima, bastaria
informar no seu contrato SCM/Residencial que as portas são filtradas
para evitar DDOS etc etc (baseando-se no Art. 9o O lá de cima), que no
fundo é isso mesmo - quando chegar alguma notificação da justiça,
anatel, governo etc, remove o filtro na frente deles e aguarda a rede
cair.

> Ninguém (governo, justiça etc) vai te enviar uma caixa de 200K pra
ficar tratando aquele DDoS de 8Gb com destino a rede dos clientes
residenciais que era só manter a forward bloqueada não. Quem prove
acesso à internet sabe que 98% desses clientes não usam essas portas,
pra que deixar aberta?

E SE o cliente precisar, libera sem problema algum pra ele as portas,
basta deixar especificado no contrato pra entrar em contato com o
suporte/noc/etc solicitando.

"Ah Elias, mas existe maneiras de pedir pros seus peer's tratarem o
ataque com filtros bgp e bla bla bla". Ah, é lindo na teoria. Na
prática, até o NOC de alguma operadora atender e entender o que tá
acontecendo, sua rede está degradada à 2 dias...


Em 21/03/2017 14:25, Fernando Frediani escreveu:
> A questão não é exatamente o que um ou outro defende, mas o que se
> pode ou não fazer.
> A Lei (sim o Marco Civil) diz de maneira muito clara que não pode
> bloquear, não importa se a razão é a mais nobre de "proteção" ao
> cliente ou não. Ela só prevê três exceções que são a porta 25 e os
> outros 2 cenários já citados aqui. Fora isso viola a Lei, simples
> assim.
> 
> Quem quiser pagar pra ver verá.
> 
> Fernando
> 
> 2017-03-21 13:24 GMT-03:00 Elias Andrade via gter <gter at eng.registro.br>:
>>         Compartilho do pensamento do Thiago e do Raul.
>>         Filtrar as portas entrantes 0-1024 e se o cliente tiver necessidade,
>> aloca ele num range de IP público (ou aloca 1 IP público) que seja
>> liberado, pois, teoricamente, esse cliente tem conhecimento do que tá
>> fazendo.
>>
>>         Um teste simples pra quem defende porta entrante em bloco de cliente
>> residencial: suba um Mikrotik (ou Ubiquiti, telefone IP, roteador wifi
>> de baixo custo) na rede e acompanhe os logs desses equipamentos. O
>> Mikrotik é o primeiro que mia se estiver habilitado o DNS recursivo
>> (Allow Remote Request), o telefone IP vai tocar o dia inteiro com falsas
>> requisições SIP e travar a interface web e o Ubiquiti, se não for
>> infectado por vírus, vai cair por "DoS".
>>
>>         Quando sobe-se um IP público na sua rede (sem filtragem), já vem uma
>> penca de requisições em cima dele tentando explorar http, https, ssh,
>> dns etc. Liberar as portas entrantes pra todos os clientes residenciais
>> traria mais problema do que solução, pois poucos clientes têm
>> conhecimento pra tratar isso em seus equipamentos (overhead urraria na
>> sua rede, o suporte de primeiro nivel de um callcenter então ficaria
>> enlouquecido).
>>
>>
>> [ ]'s
>> Elias Andrade
>>
>> Em 19/03/2017 16:39, Tiago SR escreveu:
>>> Bom, eu considero como limitação técnica plenamente justificável o bloqueio, por medida de segurança e garantia da integridade da rede (lembrar caso dos UBNTs infectados, bem como todo tipo de roteador doméstico diariamente suscetível a esses riscos), de conexões entrantes em portas baixas, bem como sendo algo que afeta a todos de maneira igual.
>>>
>>> Posso também querer bloquear portas baixas (0-1024) em IPv6, os riscos são os mesmos e até maiores (IoT vai ser um inferno).
>>>
>>>  ---- On Sun, 19 Mar 2017 16:19:48 -0300 Fernando Frediani <fhfrediani at gmail.com> wrote ----
>>>  > O NAT/CGN não é feito para se realizar bloqueio de portas e sim por uma
>>>  > limitação técnica plenamente justificável e que afeta a todos de maneira
>>>  > igual.
>>>  > Além disso o oferencimento de IPv6 já seria o suficiente para superar uma
>>>  > possível argumentação nesse sentido.
>>>  >
>>>  > Fernando
>>>  >
>>>  >
>>>  > On 19 Mar 2017 15:46, "Tiago SR" <listas at tiagosr.com> wrote:
>>>  >
>>>  > Até porque o NAT/CGN traz o mesmo efeito de bloqueio de conexões de
>>>  > entrada. Se não pode ter esse bloqueio, então também não pode fazer NAT?
>>>  >
>>>  >
>>>  >  ---- On Sun, 19 Mar 2017 12:15:43 -0300 Fernando Frediani <
>>>  > fhfrediani at gmail.com> wrote ----
>>>  >  > No caso do acesso inverso INTERNET > Cliente, não existe nada que diga
>>>  > que
>>>  >  > não se pode bloquear portas (pelo menos eu desconheço).
>>>  >  >
>>>  >  >
>>>  >  > Essa é a parte da mente fértil que eu me referi.
>>>  >  >
>>>  >  >
>>>  >  >
>>>  >  > Em 18 de março de 2017 18:30, Fernando Frediani <fhfrediani at gmail.com>
>>>  >  > escreveu:
>>>  >  >
>>>  >  > > Robson, a principio o bloqueio de portas de entrada para os clientes é
>>>  >  > > nada mais do que um filtro o que no meu entendimento é vedado pois
>>>  > deixa
>>>  >  > de
>>>  >  > > preservar o "caráter irrestrito do acesso a internet" (Art. 3 do
>>>  > Decreto e
>>>  >  > > Art. 9 do MC), embora seja amplamente aplicado por razoes diversas.
>>>  >  > >
>>>  >  > > O Decreto de Regulamentação do Marco Civil (
>>>  > http://www.planalto.gov.br/cc
>>>  >  > > ivil_03/_Ato2015-2018/2016/Decreto/D8771.htm) é bem difícil de se
>>>  >  > > compreender (bem estilo Dilma se expressar), mas em seu Art. 5 fala de
>>>  >  > > algumas situações bastante justificáveis como:
>>>  >  > >
>>>  >  > > - Restrição ao envio de Spam (bloqueio porta 25).
>>>  >  > > - Controle de ataques DDoS (bloqueio de portas ou IPs de maneira
>>>  > pontual e
>>>  >  > > restrita a fim de prevenir ou mitigar um ataque).
>>>  >  > > - Tratamento de situações excepcionais para evitar o congestionamento
>>>  > da
>>>  >  > > rede (também pontual e não de maneira permanente).
>>>  >  > >
>>>  >  > > No entanto o Art.6 parece bem genérico que abre uma leque de
>>>  >  > > possibilidades para qualquer mente fértil.
>>>  >  > >
>>>  >  > > Quer complicar mais um pouco ? O MC e o Decreto abrem brecha para
>>>  > Anatel
>>>  >  > > dar pitaco aonde ela não deveria nunca chegar perto, ou seja, a
>>>  > Internet.
>>>  >  > >
>>>  >  > > Fernando
>>>  >  > >
>>>  >  > > On 17/03/2017 17:34, Robson mendes de souza wrote:
>>>  >  > >
>>>  >  > >> Recentemente, fui questionado por cliente, sobre o bloqueio de portas
>>>  >  > >> 0-1024, que fazemos para clientes, banda larga, minha duvida é, isso e
>>>  >  > >> permitido por lei.
>>>  >  > >>
>>>  >  > >>
>>>  >  > > --
>>>  >  > > gter list    https://eng.registro.br/mailman/listinfo/gter
>>>  >  >
>>>  >  >
>>>  >  >
>>>  >  >
>>>  >  > --
>>>  >  > Andrio Prestes Jasper
>>>  >  > Skype: andriopj
>>>  >  > LinkedIn <https://www.linkedin.com/in/andrio-prestes-jasper-a98b7a11a>
>>>  >  > Celular: (65) 9320.3170 / 8444.0040
>>>  >  > --
>>>  >  > gter list    https://eng.registro.br/mailman/listinfo/gter
>>>  >  > --
>>>  >  > gter list    https://eng.registro.br/mailman/listinfo/gter
>>>  >
>>>  >
>>>  > --
>>>  > gter list    https://eng.registro.br/mailman/listinfo/gter
>>>  > --
>>>  > gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>>
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
> 



[ ]'s
Elias Andrade



More information about the gter mailing list