[GTER] Bloqueio de portas
Tiago SR
listas at tiagosr.com
Tue Mar 21 21:59:29 -03 2017
O bloqueio das portas baixas pode não impedir o DDoS, mas reduz a maior parte das chances (porque pode vir na LAN também) de que o dispositivo seja se quer infectado para começar alguns tipos de ataque, como parte de uma botnet. Primeiro ele tem que ser invadido (via SSH, Telnet, HTTP, etc.), para o malware ser injetado, não concorda?
Solução de DDoS para mim (a partir do alvo) é blackhole e mitigação com serviços adequados. Não estou falando em bloqueio de portas baixas por esse motivo, mas pode ajudar a prevenir que os ataques originem da sua rede, ao evitar que dispositivos sejam infectados para isso.
No UDP é mais complicado para fazer um bloqueio do tipo (alguma ideia de como diferenciar novas conexões entrantes de apenas respostas a requisições feitas nesse protocolo?), mas fazer apenas no TCP já deve trazer bons resultados.
---- On Tue, 21 Mar 2017 19:16:03 -0300 Eduardo Bragatto <eduardo at bragatto.com> wrote ----
> 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
>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list