[GTER] Bloqueio de portas

Elias Andrade esan_br at yahoo.com.br
Tue Mar 21 22:15:26 -03 2017


	Em que parte eu respondo sobre bloquear especificamente a porta 80/tcp
e 443/tcp com destino ao usuário residencial? Respondi o range de portas
0-1024 (independente do protocolo).

	Exemplo?
	Sobe um GNS3 com 3 equipamentos e simula que o do meio é o roteador de
borda do provedor/operadora. Sobe netcat com uma porrada de requisicao
no IP da outra ponta e acompanha o resultado (não esqueça de usar um
"processador" chuleta como roteador do cliente e com pouca memoria).
Habilita e desabilita a filtragem de encaminhamento das portas no
roteador do meio e veja se bate conexão nas portas UDP ou TCP da outra
ponta. Multiplica essa galera residencial por 1000/5000/10000 e usando
XPON pra ver no que dá.

	Se tem dúvidas sobre DDoS em cima destes serviços, acompanhe a Bugtrack
e veja o número de equipamentos, firmware, softwares, S.O etc etc que
vive bugado. Se um ataque fosse parar unica e exclusivamente esse
equipamento do cliente... estaria ótimo! Mas DDoS é muito mais do um
serviço rodando na porta XYZ/tcp na ponta do cliente: DDoS (devido à
aquele login e senha padrão que um técnico de informática deixou na casa
do cliente e agora o bagulho virou um zumbi na rede) são as suas caixas
topando PPS (ou overhead em tudo que é ativo na rede de transporte da
operadora) por causa de besteira.

	Uma coisa é o usuário final ser da nossa área, usando as proteções
corretas em suas bordas "residenciais" e sabendo o que tá fazendo (e se
sabe o que tá fazendo, entra em contato com o provedor/operadora e pede
pra liberar as portas) e outra é a tiazinha/tiozinho/garotada que só usa
a internet pra faceboca, zapzap, xhamster e etc tomando conexão no seu
ip público "filter-less" do roteadorzinho dele (e reclamando no
callcenter do provedor/operadora).

	Resumindo: o que eu to vendo é um monte de gente defendendo filter-less
na sua ponta e esquecendo que a grande maioria dos usuários hoje em dia
são de IoT.

	"Deixar essa p* sem filtragem vai dar m*, capitão!"


[ ]'s
Elias Andrade

Em 21/03/2017 19:16, Eduardo Bragatto 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.
> 
> 
> 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