[GTER] Bloqueio de portas
Eduardo Bragatto
eduardo at bragatto.com
Tue Mar 21 19:16:03 -03 2017
Meu caro,
Você pode me esclarecer como que bloquear portas baixas TCP impede qualquer ataque DDoS?
Os ataques mais comuns hoje são de reflexão e amplificação DNS e NTP — que usam portas UDP que você simplesmente não pode bloquear (os processos de mitigação desses ataques são muito mais complexos do que simplesmente filtra uma porta inteira).
Como que bloquear a porta 80 ou 443 impede DDoS? Todos os ataques de reflexão dependem de protocolos connectionless (como UDP e ICMP) — bloquear qualquer porta TCP não irá fazer a menor diferença nesses casos.
Poderia nos dar um exemplo de um tipo de ataque DDoS que pode ser evitado bloqueando a porta TCP/80 ou TCP/443? Gostaria muito de entender que tipo de ataque é esse ao qual você se refere.
Att
Eduardo Bragatto
> On 21 Mar 2017, at 16:38, Elias Andrade via gter <gter at eng.registro.br> wrote:
>
> 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
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list