[GTER] RES: ARP Poisoning / Mesmos IPs na rede

[Victor Benincasa]

A questão é que se o datacenter não utilizar uma filtragem MAC ou VLAN 
por cliente,
que são quesitos de segurança *sob controle deles*, a rede fica 
vulnerável, sujeita a
interrupções e captura de tráfego.

O próprio SLA de um datacenter sempre irá prever uma razoável 
disponibilidade de rede,
independente de qual produto comprado, e como isso é possível se o seu 
produto está
fora do ar por uma falha no roteador do datacenter, que está 
direcionando o tráfego do
seu servidor para uma outra máquina?

No meu caso mesmo o datacenter irá descontar 100% da próxima mensalidade 
por
conta das mais de 24h com intermitência no acesso (o SLA deles prevê 
desconto
de 5%/hora).

E a .comDominio não era referencia de qualidade de qualquer forma... 
Lembro até hoje
dos inúmeros problemas que tive por lá. Certa vez precisei restaurar um 
backup remoto
(tinha o serviço contratado), eles alegaram que a "janela" do sistema de 
backup deles
só possibilitava a restauração durante algumas horas do dia, e nestas 
horas, o backup
antigo já teria sido sobrescrito... Essa serviu para fechar a minha 
conta com eles com
chave de merda! E sei não se a coisa melhorou por lá depois que foram 
comprados pela
Alog... Esses dias mesmo vi um pessoal daqui discutindo sobre um 
downtime de dias, com
direito a servidores queimados, etc...

Victor Benincasa


On 3/8/2011 16:17, Antonio Carlos Pina wrote:
> Discordo que isso seja "erro grosseiro" do datacenter ou "mau-serviço
> prestado", pois eu já vi esse tipo de prática em vários datacenters.
>
> É necessário analisar se há um desalinhamento sobre QUAL PRODUTO está sendo
> comprado.
>
> Eu lembro que a .comDominio oferecia a venda de um produto chamado SPOT cuja
> descrição era "1 IP público de uma rede compartilhada configurado em Vlan
> compartilhada" e a ALOG herdou este produto
>
> O datacenter erra se não deixar isso claro. E evidentemente o cliente pode
> querer algo diferente ou não.
>
> Abs
>
> Em 3 de agosto de 2011 15:57, Toledo, Luis Carlos<lscrlstld at gmail.com>escreveu:
>
>> Erro grosseiro de alocação de IP pelo IDC, sem VLAN e sem filtro de MAC.
>>
>> Não tem como você se proteger pois não tem gerência do switch e/ou roteador
>> que te atende, exija um serviço de melhor qualidade.
>>
>>> Concordo com o amigo Rafael, eu correria sem olhar para trás de um
>>> DataCenter que faz isso!
>>>
>>> Sds,
>>>
>>> 
>>> Marcelo Marques Pinheiro
>>> NipBr - NipCable do Brasil LTDA.
>>> (12)2138-8000.
>>>
>>>
>>> Em 03/08/2011, às 14:55, Rafael Cresci<cresci at gmail.com>  escreveu:
>>>
>>>> O datacenter deveria, como boa prática, alocar somente blocos CIDR e
>>> separá-los em VLANs individuais por cliente (ou por máquina), e nunca
>>> colocar todo mundo numa mesma VLAN.
>>>> Não fazer isso é coisa de amador, a menos que tenha MAC Address
>>> filtering...
>>>> []s
>>>> Rafael Cresci
>>>>
>>>> On 03/08/2011, at 14:45, Victor Benincasa wrote:
>>>>
>>>>> Contratei um dedicado para testes em um datacenter, mas a interface de
>>> rede
>>>>> parecia "cair" a todo instante após alguns dias. Descobri que o
>>> servidor de um
>>>>> outro cliente deles, na mesma subrede (/24), foi indevidamente
>>> configurado
>>>>> com os IPs do meu dedicado.
>>>>>
>>>>> Imagino que com a configuração incorreta, a tabela ARP do roteador do
>>>>> datacenter acabava associando o meu IP à interface do outro servidor
>>> (este é
>>>>> o principio o ARP poisoning, não?) e meu tráfego era redirecionado
>> para
>>> lá.
>>>>> Queria, então, uma luz de vocês. Quais as formas efetivas de se
>>> contornar o
>>>>> problema? Só me ocorre usar tabela ARP estática. O isolamento de meus
>>> IPs em
>>>>> uma subrede menor ajudaria será?
>>>>>
>>>>> Abraços,
>>>>>
>>>>> --
>>>>> Victor Benincasa
>>>>>
>>>>> --
>>>>> 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