[GTER] Bloqueio de portas

Tue Mar 21 20:37:58 -03 2017

> Em 21 de mar de 2017, à(s) 19:16, Eduardo Bragatto <eduardo at bragatto.com> escreveu:
> 
> 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.

Acho que você esqueceu que esses ataques não precisam, necessariamente, ser de estouro de banda.

Ataques em TCP são mais comuns do que você deve imaginar..  sem entrar em méritos técnicos, imagine um atacante apenas direcionando inúmeras requisições ( o início delas ) para seu servidor, e a cada uma delas, seu servidor alocando recursos.

Muitas requisiçoes, pouco tráfego, e tchau.

Agora, se você não fala do serviço em específico, mas sim como essas portas sendo utilizadas como entrada. Se todos fizessem isso, por exemplo, o worm que atingiu a ubnt não teria tanto impacto, já que a primeira versão dele dava bypass na autenticação web.

Assim foi também com o MK no caso da CIA.

Assim foi o caso dos DVRs que foram utilizados pra ataques.

E Etc.

Que apesar dos ataques não serem direcionados a essa porta específica. DDOS em TCP é mais comum do que vc imagina.

Elizandro Pacheco

> 
> 
> 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
> 
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter