[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