[GTER] RES: planos e velocidades Em Fibra Otica

Fri May 8 10:26:05 -03 2015

Não vejo problema se for parte de uma estratégia maior. Ajuda a eliminar
ameaças triviais, script kids, etc. É que nem deixar mochila visível dentro
do carro... Chama o ladrão de ocasião.

Carlos Ribeiro
Em 08/05/2015 09:51, "Douglas Fischer" <fischerdouglas at gmail.com> escreveu:

> Segurança por obscuridade...
> A história fala sobre a real eficácia disso.
>
> Em 8 de maio de 2015 08:57, Soares <soares at tecnetce.com.br> escreveu:
>
> > Aqui todas o AP dos clientes usa uma porta diferente.
> > Tipo 3030, 4040
> >
> > E os equipamentos de gerencia com portas diferentes para SSH.
> >
> >
> >
> >
> > -----Mensagem original-----
> > De: gter-bounces at eng.registro.br [mailto:gter-bounces at eng.registro.br]
> Em
> > nome de Carlos Ribeiro
> > Enviada em: quinta-feira, 7 de maio de 2015 23:00
> > Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> > Assunto: Re: [GTER] planos e velocidades Em Fibra Otica
> >
> > Em tese, a operadora não deveria precisar usar gerência "in band" nessas
> > portas, porque isso faz parte do espaço de endereçamento cedido ao
> cliente.
> > A maioria das tecnologias permite a entrega do circuito com algum tipo de
> > gerência "out of band"...
> >
> > O fato de precisar da porta 80 ou 22 é porque a operadora está cedendo o
> > roteador, que (em tese) poderia ser do cliente. E nesse caso o roteador
> > pode ser reconfigurado de forma que seja administrado em outras portas (o
> > que inclusive é recomendado por algumas pessoas), fazendo um
> > redirecionamento destas portas para servidores do cliente.
> >
> > Tudo isso posto, 99.99% das pessoas não implicaria com isso. Então é só
> > tratar as exceções!
> >
> > Carlos Ribeiro
> > Em 07/05/2015 22:33, "Marcos Diego" <marcos at turbonetbr.com.br> escreveu:
> >
> > > Justamente estas que eu não abriria em um plano residencial
> > > Principalmente a 80 e 22 que são de gerência do equipamento
> > >
> > > Marcos
> > >
> > > Enviada do meu iPhone
> > >
> > > > Em 07/05/2015, às 16:04, Rafael Possamai <rafael at gav.ufsc.br>
> > escreveu:
> > > >
> > > > Um nerd como eu gostaria de poder fazer um pedido de abertura de
> > > > certas portas, por exemplo 22/80/443. :)
> > > >
> > > > 2015-05-07 12:10 GMT-05:00 Gustavo Stocco <gustavostocco at gmail.com>:
> > > >
> > > >> Olá Rafael,
> > > >>
> > > >> Nós fazemos o bloqueio nas portas baixas (0 até 1024 - TCP) dos
> > > >> clientes residenciais.
> > > >> Sempre funcionou belezura!
> > > >>
> > > >> 2015-05-07 11:35 GMT-03:00 Rafael Galdino
> > > >> <sup.rafaelgaldino at gmail.com
> > > >:
> > > >>
> > > >>> Trabalhei em um provedor Diginet em Natal-RN onde eles faziam os
> > > >>> blocks
> > > >> de
> > > >>> portas baixas 1-1024 TCP
> > > >>>
> > > >>> isso alguém ainda faz?
> > > >>>
> > > >>> outra coisa para esse serviço seria interessante utilizar de
> > > >>> apliances digamos para ofertar ao cliente:
> > > >>> * Filtro de emails spam
> > > >>> * Filtro de urls maliciosas "anti-virus"
> > > >>> * sistema de cache "seja ggc, akamai, cache de conteúdo"
> > > >>> * acelerador de wan
> > > >>>
> > > >>>
> > > >>> pois penso que se é um produto novo e inovador, acredito ser
> > > >>> melhor
> > > fazer
> > > >>> logo no inicio da rede.
> > > >>> concordam?
> > > >>>
> > > >>>
> > > >>> Em 7 de maio de 2015 08:56, Carlos Menandro
> > > >>> <carlosmenandro at gmail.com>
> > > >>> escreveu:
> > > >>>
> > > >>>> Cuidado com os torrents, eles sugarão toda a banda de upload se
> > > >>>> você
> > > >>> deixar
> > > >>>> simétrico.
> > > >>>>
> > > >>>> Sobre servidores em casa, faça como a Oi, block nas portas
> padrões.
> > > >>>>
> > > >>>> Coloque limite, mas com uma banda suficiente para o cliente
> > > >>>> conseguir
> > > >> ser
> > > >>>> host de uma partida de jogos e/ou fazer um streaming de quando
> > > >>>> estiver jogando.
> > > >>>>
> > > >>>> Essa é minha visão de cliente das necessidades básicas.
> > > >>>>
> > > >>>> Em 7 de maio de 2015 05:52, Bruno Araújo <bjaraujo at gmail.com>
> > > >> escreveu:
> > > >>>>
> > > >>>>> Limitar o upload também minimiza o estrago de ataques partindo
> > > >>>>> de sua
> > > >>>> rede.
> > > >>>>>
> > > >>>>> _______________
> > > >>>>> Bruno Araújo
> > > >>>>>
> > > >>>>>
> > > >>>>> Antes de imprimir, verifique se tem papel e tinta suficiente na
> > > >>>> impressora.
> > > >>>>>
> > > >>>>> Em 06/05/2015, às 15:10, Fernando Frediani
> > > >>>>> <fhfrediani at gmail.com>
> > > >>>>> escreveu:
> > > >>>>>
> > > >>>>>> Existem razões técnicas e comerciais para se limitar o Upload
> > > >>>>>> em
> > > >>>>> conexões residenciais.
> > > >>>>>>
> > > >>>>>> *Técnicas*:
> > > >>>>>> - Transporte não permite velocidades simétricas (e.g: ADSL)
> > > >>>>>> - Maior possibilidade de congestionar o POP no caso de rádio já
> > > >>>>>> que
> > > >>> ele
> > > >>>>> opera em half-duplex
> > > >>>>>> - No caso de Fibra GPON até daria pra oferecer para velocidades
> > > >>>> menores,
> > > >>>>> mas a velocidade máxima do transporte é como no ADSL (aprox: 2,5
> > > >>>>> Gbps
> > > >>>> para
> > > >>>>> Down e 1,25 para Up) então isso poderia quebrar a conta de
> > > >>>>> velocidade alocada ou lá na frente quando a demanda por
> > > >>>>> velocidades maiores
> > > >>> chegar.
> > > >>>> Ja
> > > >>>>> no caso do EPON não seria um problema do ponto de vista técnico.
> > > >>>>>>
> > > >>>>>> *Comerciais*:
> > > >>>>>> - Hospedagem de serviços 'em casa' tirando receita da
> > > >>>>>> hospedagem em
> > > >>>>> Datacenter.
> > > >>>>>> - Mesmo com toda a questão legal já discutida aqui, a
> > > >>>>>> utilização da
> > > >>>>> conexão para revenda: Um link não simétrico acaba dificultando
> > isso.
> > > >>>>>> - Compartilhamento da conexão por muitos usuários: Um número
> > > >>>>>> maior
> > > >> de
> > > >>>>> usuários atrás de uma conexão residencial/comercial acaba
> > > >>>>> saturando
> > > >>> mais
> > > >>>>> rapidamente o upload antes do download, o que forca o cliente a
> > > >>> contratar
> > > >>>>> uma conexão com velocidade de upload maior para resolver o
> > problema.
> > > >>>>>>
> > > >>>>>> Fernando
> > > >>>>>>
> > > >>>>>>> On 06/05/2015 14:44, Sergio Jose Ferreira wrote:
> > > >>>>>>> Não existe motivo técnico, existe motivo comercial.  É porque
> > > >>>>>>> um
> > > >>>>> circuito full-duplex cobra-se R$ 300,00,  R$ 350,00 ou até R$
> > > >>>>> 500,00
> > > >>> por
> > > >>>>> Mbits  do usuário final neste tipo de serviço e no banda larga
> > > >>>>> sai
> > > >> mais
> > > >>>> ou
> > > >>>>> menos R$ 10,00 por Mbits.  Só por isso :-)
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> Em 06/05/2015, à(s) 14:30, Pablo de Souza <
> > > >>> pablo at mastervicosa.com.br
> > > >>>>>
> > > >>>>> escreveu:
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Limitar download pela resposta?
> > > >>>>>>>>
> > > >>>>>>>> Em 06.05.2015 13:54, Bruno Cabral
> > > >>>>>>>> escreveu:
> > > >>>>>>>>
> > > >>>>>>>>> Um uso é limitar o download pela resposta (upload)
> > > >>>>>>>> !3runo Cabral
> > > >>>>>>>>>> Agora pensando como cliente, uma pergunta
> > > >>>>>>>> pertinente: Se o acesso é por fibra por que não oferecer um
> > > >>>>>>>> link full-duplex? E vou além, se a maioria absoluta dos
> > > >>>>>>>> usuários não
> > > >> faz
> > > >>>>>>>> upload massivo por muito tempo, tecnicamente qual o
> > > >>>>>>>> impeditivo
> > > >> para
> > > >>>>>>>> prover uma taxa de upload melhor? Vale para outros colegas da
> > > >> lista
> > > >>>> que
> > > >>>>>>>> forem ISP...
> > > >>>>>>>>> --
> > > >>>>>>>>> gter list
> > > >>>>>>>> https://eng.registro.br/mailman/listinfo/gter [1]
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>>
> > > >>>>>>>> ------------------
> > > >>>>>>>> Pablo de Souza
> > > >>>>>>>> Analista de Redes
> > > >>>>>>>> Graduado em Redes
> > > >>>>>>>> de Computadores
> > > >>>>>>>> Linux/Mikrotik/Shell Script Junior Developer
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Links:
> > > >>>>>>>> ------
> > > >>>>>>>> [1] 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
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>>
> > > >>> *Rafael Galdino*
> > > >>>
> > > >>> *      Analista de redes - Inexa Tecnologia *
> > > >>>
> > > >>>      Phone:  *+55 (66) 2101-8000*
> > > >>>
> > > >>>      Celular: *+55 (66) 8102-8521* TIM
> > > >>>
> > > >>>                     *+55 (66) 9986-4408 *VIVO
> > > >>>
> > > >>> *Avenida Rui Barbosa, 2033**, Centro Rondonópolis - MT*
> > > >>> --
> > > >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> Gustavo Stocco
> > > >> GNet Telecomunicaçõeshttp://www.gnettelecom.com.br
> > > >> +55 (47) 3373-3322
> > > >> 0800-932-0000 R.3322
> > > >> INOC-DBA BR 53001*100
> > > >> --
> > > >> 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
> >
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter