[FUG-BR] RES: [OFF TOPIC] Re: The Internet's Biggest Security Hole

[Adalto Lima Moreira]

2008/8/29 c0re dumped <ez.c0re em gmail.com>

> Adalto, também peço desculpas a você e aos demais da lista pelo tom da
> minha resposta. Não sei quanto aos outros , mas achei seu primeiro
> quote em meu e-mail e logo depois no do Renato, bem arrogantes.


concordo que tenha parecido,
não foi intencional
a mesma coisa sobre o php la, o outro menino se sentiu ofendido
infelizmente não tenho costume de por os "he he he" e "ha ha" e carinhas em
e-mail
o que o torna passível de má interpretação quando digo algo que não gostem
rs



>
>
> Mas nada justifica minha atitude. Novamente, desculpas a você e todos
> os outros membros.


nos excedemos
mas acredito que já voltamos a contribuir para a qualidade desta


> No nosso caso que usamos hardware Cisco, já tem uns 3 anos que não
> temos nenhum downtime por conta de falha de hardware ou IOS nos
> routers. Quando precisamos foi menos de 5 minutos entre a abertura do
> chamado e a solução do problema, com o router 100% funcional.


perfeitamente, não sugiro sob qualquer hipótese o equipamento, sistema e
suporte
profissional não se de qualidade, especialmente juniper
por outro lado você contou com sorte, não houve problema elétrico
já cansei de ver eprons cisco morrendo, e IOS corrompendo o IOS que é
comprimido
no momento do boot
alias só o fato de ter o sistema comprimido já me causou motivos de problema
fico feliz que tenhas dado sorte suficiente para ter esse profiling

no meu caso prefiro não depender da sorte e ter fail-over de tudo
o que eu sei que dependendo do ambiente, o custo de ter box de roteadores
enormes redundante
é proibitivo
ao ponto de sabermos que até mesmo as maiores operadoras contam com a sorte
e não dispõe de redundancia em muitos de seus POP



> Trabalho com Free e UNIX há alguns anos e sei que pra certos problemas
> mais cabeludos, por mais que se tenha experiência com o sistema, com a
> ferramenta, com o hardware e tudo o mais, estes problemas demandam
> tempo para serem resolvidos: procura nos logs, debuga o processo,
> testa configuração A, testa configuração B, olha mensagens de erro no
> console, procura no google, pergunta em ML... e por aí vai.


por isso defendo que cada nova implantação deve ser testada antes de por em
produção
um processo de QAS mesmo que baseado em 1 ou 2 pessoas só, deve homologar
não se sai juntando openvpn, placa aceleradora de crypto, quagga, e
mahakeshis da vida
sem testar antes
cada solução deve ser testada antes
o vantajoso é que criamos as soluções
não dependemos se o fabricante fornece ou não
veja a trabalheira da cisco para suporte ipv6 adequadamente... e veja os
tuneis
teredo padrão do windows vista gerando dores-de-cabeça mil para quem tem
IOS ou CatOS com ipv6 habilitado na rede, ou ainda o horror que é comprar
uma solução de análise de netflow da cisco (a mãe da tecnologia) e descobrir
que
a solução não analisa o flow gerado por alguns junipers porque este, só gera
flow sampleado
e alguns períodos de sampling são incompatíveis

tudo tem seus pros e contras, como você mesmo disse
e é natural que se o fabricante oferece um "produto", o mínimo que esperamos
é que ele funcione

façamos o mesmo com nossos recursos implantados




> Você melhor que ninguém sabe que um cliente que acordou um contrato
> pedindo X% de disponibilidade, não vai dar a mínima para o motivo do
> problema, qualquer que seja ele.


sem dúvidas
e ele está certíssimo

Como disse antes, existem casos e casos. Acredito que para quem tem
> uma estrutura mais compacta e quer oferecer a melhor relação
> custo/benefício ao cliente, a abordagem adotada por vc, pra citar um
> exemplo, talvez seja a ideal.


não acho minha estrutura compacta
talvez seja, comparando à sua, é fato
mas são 4 bordas bgp em 2 capitais diferentes, e são dezenas de clientes
usando a solução de roteamento mencionada
a distribuição da solução é muito fácil e organizada
alias a maioria dos equipamentos eu criei uma pequena estrutura de
provisionamento
via scp, e portanto eu dispacho o equipamento, o cliente liga, e ele se
auto-configura
assim que detecta conectividade, se não detectar, a equipe de campo faz o
check-list
bem simples


> Imagina eu trocar todos os meus CEs por PCs, botando um ou dois spares
> pra cada.


sim, imagino, foi o que eu fiz quando dispensamos cisco
o TCO deixou o financeiro feliz da vida,
e eu ainda mais por finalmente ter redundância plena


> Imagina uma atualização de segurança pro OS ultra-mega-super
> urgente que envolva uma nova compilação de kernel


nesse caso fico feliz em não ter cisco, pois openbsd e freebsd tem response
time
de segurança muito mais adequados, e de olho aberto nos commit logs já
podemos
nos antecipar antes mesmo do adivisory ser lançado


> Imagina uma queda de energia que danifique
> o sistema de arquivos inviabilizando o boot na máquina.


com memória flash montada RO, improvável
precisaria ser um problema físico/elétrico
caso em que nenhuma box fechada se porta diferente



> Imagina que
> tem que se trocar uma placa, mas a placa que vc comprou não funciona
> pq ninguem fez um driver pra ela ainda


seria exatamente a mesma coisa que comprar um módulo ether pra um chassis
incompatível ou tendo versão incompatível do IOS: em ambos os casos a falha
é na tomada de decisão e não no produto

e pra lascar tudo, a placa
> antiga não é mais fabricada...


equivalente a precisar de um módulo para chassis antigo, ou módulo antigo
para IOS antigo

ter um hardware proprietário só torna tudo mais complicado
porque as possibilidades de problema são as mesmas
enquanto ter hardware convencional, você pode rapidamente conseguir outra
placa
compatível com o sistema, sem precisar negligenciar confiabilidade

e na verdade o que costuma acontecer é você ter que trocar para um hardware
melhor
por exemplo, tirar uma `fxp` porque não é mais fabricada e colocar uma `em`

enfim, são muitas variáveis a se
> considerar quando se adota i386 numa rede desse porte.


eu vejo mais vantagens do que desvantagens
a desnvantagem é a menor vida útil de periféricos
e também as partes móveis
todas amenizadas amplamente com adoção de hardware de qualidade
e se preferir com adoção de boards integradas

pra implantação massiva, da até pra pedir pra uma FIC-Brasil da vida adaptar
suas boards de thin client para maiore expansão e processamento
se necessário for ainda
pois comparando ao poder de processamento usualmente necessário
as mesmas boards sem qualquer modificação atendem


> Acredito ser pouco provável, mas se um dia a Cisco ou Juniper vierem a
> ser seriamente ameçadas por i386,


nesse ponto, penso que o mais provável é que tornem-se i386 (ou equivalente,
amd64, etc)
pois eles também sabem que a relação custo/benefício é melhor
porém, isso leva tempo

alias vários junipers são x86 já



> No fim das contas o que os tomadores de decisão querem, é uma garantia
> que caso alguma cagada aconteça, ela seja sanada o mais rapidamente
> possível e que de preferência, ofereça muitas e muitas facilidades.


concordo
e pra isso já mencionei que há soluções
aqui mesmo na lista já implantei ou instrui por telefone provedores inteiros
a
substituir cisco por mikrotik, inclusive fazendo bgp
e pelo que sei continuam até hoje

o provedor chegou a um tamanho X, a operadora resolveu entregar fast na
porta
do provedor, ele vai para uma solução baseada em hardware convencional
isso é fato
precise de bgp ou não

devemos ter inumeros casos aqui
como temos no gter



> Eles não ligam se isso vai ser em Free, em Open, em Linux, em Cisco ou
> Juniper. Eventualmente o fator preço pode ou não determinar a vitória
> da solução X sobre a solução Y.


concordo, tem que ter qualidade e viabilidade
soluções baseadas em open source e hardware genérico podem ser assim
é isso que tenho defendido apenas



> Quanto a questão de aprender a mexer com a nova ferramenta
> (i386+OS+Software que faz o roteamento) não acho seja um ponto tão
> dificultador, pois como já diz o ditado, " a necessidade faz o homem".


concordo e vou além, é muito mais fácil, a gama de documentação online,
listas e historicos de listas
e obter respostas direto dos desenvolvedores sem ter contratos grandes
fechados, é só mais um fator favorável

o indivíduo que fica fazendo route-map no cisco, vai amar fazer as mesmas
coisas no
openbgp ou openospf, simplesmente porque é mais inteligente

o individuo que só souber openbgp e tiver q fazer no cisco ficará incomodado
com
a dificuldade desnecessária para alcançar objetivos simples

e quem adotar tal solução consegue mais fácil, e provavelmente mais barato,
free-lancers
capacitados para mexer em open source, do que em cisco ou juniper, caso não
tenha RH capacitado
internamente


> Se fossem usuários comuns, até seria um fator de peso, mas estamos
> falando de técnicos. Basicamente a mensagem é: ou aprende ou tá
> demitido.


sim
se conseguem aprender cisco e suas sintaxes não intuitivas
que dirá de uma solução open source típica (não vale quagga)

bom fds a todos