[GTER] Boas Praticas - Router de Borda

[Douglas Fischer]

Sou radicalmente contra ​proteção por obscuridade.
É algo que:
 - Em escala, dá trabalho para implementar.
 - Complica a ativação de ferramentas de gerência centralizada.
 - Torna a gerência algo mágico, acabando com a sensação de transparência
na operação.
   Fica aquela coisa de que só o cachorro que escondeu o osso pode
encontrá-lo[1].



Se vai se gastar energia para implementar algum tipo de controle extra, por
que não fazer o que é melhor prática?
 - Porque não uma sub-rede específica para gerência de CPEs?
 - Porque não colocar Vlan de Gerência mesmo nos CPEs?
 - Porque não colocar regras bloqueando acesso vindo da LAN do CPE para
essa Vlan e faixa de rede de gerência?

OK, a Vlan é bem mais complicado de se implementar e depende de
configurações nos paineis.
Mas a faixa de rede de gerência não é tão complexa assim.

E tendo isso tudo bem amarradinho, uma atualização massiva de firmware vira
em apenas alguns cliques.
Não faz mais sentido gastar algumas horas a mais agora para não sofrer
depois?



Em 28 de maio de 2016 18:48, Lucas Willian Bocchi <lucas.bocchi at gmail.com>
escreveu:

> Pessoal.
> Sigam a regra do KISS (Keep It Simple, <corte>). Em nenhum dos
> provedores que dou suporte, enfrentei este problema, por que lá adotei
> a simples política de
> 1) Mudar as portas padrões dos serviços
> 2) Criar algumas regras para limitar o acesso de fora da rede desses
> equipamentos
>
> Sei que não é a melhor solução (tem ótimas aqui, a melhor é a de rede
> de gerência, etc) mas não perdi nem uma noite de sono, nem eu, nem
> meus clientes, com estes problemas. A única coisa que cobrei de alguns
> deles foi que atualizem os firmwares assim que possível para não terem
> problemas futuros.
>
>
>
> Em 28 de maio de 2016 11:35, Flavio Rescia Dias
> <flavioresciadias at gmail.com> escreveu:
> > Pessoal,
> >
> > Excelente thread, tanto tecnicamente, sobre experiência e humildade.
> >
> > Voltando, aos topicos de boas práticas, poderiamos até em pensar em
> > compilar tudo isso em uma cartilha/serie de videos.
> >
> > Outros itens:
> > - Base de usuário de gerenciamento centralizadas sempre que possível (AAA
> > melhor ainda);
> > - Política e Ambiente de homologação, principalmente para atualização de
> > firmware (um pouco na contramão dos apressadinhos);
> > On May 28, 2016 9:05 AM, "Henrique de Moraes Holschuh" <hmh at hmh.eng.br>
> > wrote:
> >
> >> On Fri, 27 May 2016, Douglas Fischer wrote:
> >> > 2016-05-27 12:38 GMT-03:00 Henrique de Moraes Holschuh <
> hmh at hmh.eng.br>:
> >> > > On Fri, 27 May 2016, Douglas Fischer wrote:
> >> > > > Mas que seria bem lindo a possibilidade de um Control-Plane
> >> serapado, com
> >> > > > direito a VRF de gerência, seria! NÉ?
> >> > >
> >> > > A capacidade de implementar isto existe via network namespaces, mas
> >> teria
> >> > > que ser feito na unha.  Boa sorte.
> >> >
> >> > Não tenho certeza se eu sei do que você está falando...
> >> > - É diferente do VRF / Routing Mark?
> >>
> >> Network namespaces é o VRF do Linux kernel, falei sobre eles muito tempo
> >> atrás numa GTER, não lembro mais qual.  Cada namespace suas próprias
> >> interfaces de rede, e tabelas de roteamento.  Parece uma VM.
> >>
> >> Se for o Linux kernel quem está encaminhando/roteando os pacotes, é a
> forma
> >> certa de se implementar VRFs "de verdade" (que isolam *tudo*) sem ter
> que
> >> apelar para VMs.  Quem usa "containers" conhece bem esses namespaces.
> >>
> >> Agora, se a caixa tem o plano de dados fora do kernel de alguma forma
> (ver
> >> "Cumulus Linux" e "switchd" para o exemplo típico onde se empurra o
> plano
> >> de
> >> dados para um ASIC), não é o kernel quem está encaminhando ou roteando
> >> pacote no plano de dados, e network namespaces não se aplicam.
> >>
> >> > Tá falando de ir lá no linux?
> >>
> >> Sim.
> >>
> >> > O RouterOS tem open v-switch nativo?
> >>
> >> Não sei, e desconfio seriamente que estou mais feliz não sabendo...  até
> >> onde sei, há o risco do RouterOS ter re-implementado todo o plano de
> dados
> >> em userspace.  Explicaria muita coisa (isso não é um elogio).  Considero
> >> pouco provável, entretanto.
> >>
> >> > P.S.: Como ficou evidente, conheço pouco do aspecto construtivo do
> >> RouterOS.
> >>
> >> Quando você olha dentro do abismo por tempo demais, corre o risco dele
> >> olhar
> >> de volta para você, e te tragar para as profundezas.
> >>
> >> Por essas e por outras, evito lidar com coisas que considero uma
> afronta a
> >> tudo que é bom e belo nesse mundo...
> >>
> >> --
> >>   "One disk to rule them all, One disk to find them. One disk to bring
> >>   them all and in the darkness grind them. In the Land of Redmond
> >>   where the shadows lie." -- The Silicon Valley Tarot
> >>   Henrique Holschuh
> >> --
> >> 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