[GTER] Bloqueio de portas

Tue Mar 21 14:25:47 -03 2017

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