tranquilo Em 10 de maio de 2010 17:18, Renato <[email protected]> escreveu:
> Desculpa, já foi e voltou tanta mensagem que eu fiquei perdido. > > > > *De:* [email protected] [mailto: > [email protected]] *Em nome de *Noilson Caio > *Enviada em:* segunda-feira, 10 de maio de 2010 17:07 > > *Para:* [email protected] > *Assunto:* Re: [slack-users] MAC CLONADO. > > > > Meu problema ? Não amigo, essa thread é do Ronaldo Santos :) > > Em 10 de maio de 2010 17:11, Renato <[email protected]> escreveu: > > Do ponto de vista lógico eu concordo contigo. Mas o cliente não fica > permanentemente em contato com o servidor DHCP: ele conecta, solicita > o IP, recebe e desconecta. > > Por causa disso tu não consegue diferenciar casos onde o cliente > desconectou por um motivo como desligar ou cabo de rede do switch ou > onde o cliente simplesmente manda um request sem dar um release antes > e isso abre potencial para ataques de DOS, uma vez que um cliente pode > mandar vários requests até que o servidor deixe de responder (ou pior, > um cliente pode pegar todos os endereços de uma rede). > > O exemplo da falta de endereços não foi exatamente uma boa idéia, > considerando o caso onde tu tem uma reserva para um mac. Era mais algo > num sentido geral (afinal, este tipo de verificação deveria ser feita > sempre ou na maioria dos escopos e não só no host). > > Acho que esse é o ponto. Se o servidor fizer a verificação geral sempre, o > problema do Noilson provavelmente não aconteceria, porque o servidor > verificaria antes que já há um cliente usando aquele IP. > > > -----Mensagem original----- > De: [email protected] [mailto: > [email protected]] > Em nome de Max Miorim > > Enviada em: segunda-feira, 10 de maio de 2010 16:43 > > Para: [email protected] > Assunto: Re: [slack-users] MAC CLONADO. > > On 5/10/10, Renato <[email protected]> wrote: > > Mesmo assim, as implementações de servidor DHCP do linux que eu conheço > > (dnsmasq e dhcpd3) não fazem isso e um dos motivos é bem > > simples: se o cliente perder o link por algum motivo, não vai haver o > > "release" de forma adequada, para o servidor o IP continua alocado e em > uso. > > > > Ao reestabelecer o link, se houvesse tal bloqueio na hora da liberação, > este > > cliente seria incapaz de utilizar o mesmo endereço e isso poderia > resultar > > numa série de problemas (falta de endereços disponíveis, ter que forçar o > > cliente a dar o "release" e depois "renew" e etc.) > > > >> Eu não concordo. Se o cliente perder o link não haverá problemas em > > restabelecer o IP, já que ele vai estar amarrado ao MAC do cliente, não > > haverá falta de endereços porque o MAC já estará amarrado e o DHCP não > vai > > liberar outro IP para aquele MAC. O cliente por sua vez não vai precisar > de > > dar o release nem o renew, já que o DHCP ainda está autenticando aquele > MAC > > amarrado. Mas o que aconteceria é que o DHCP não iria liberar a conexão > para > > o cliente de jeito nenhum, o que levaria o administrador a encontrar o > > problema no olho e solucionar manualmente. > > Do ponto de vista lógico eu concordo contigo. Mas o cliente não fica > permanentemente em contato com o servidor DHCP: ele conecta, solicita > o IP, recebe e desconecta. > > Por causa disso tu não consegue diferenciar casos onde o cliente > desconectou por um motivo como desligar ou cabo de rede do switch ou > onde o cliente simplesmente manda um request sem dar um release antes > e isso abre potencial para ataques de DOS, uma vez que um cliente pode > mandar vários requests até que o servidor deixe de responder (ou pior, > um cliente pode pegar todos os endereços de uma rede). > > O exemplo da falta de endereços não foi exatamente uma boa idéia, > considerando o caso onde tu tem uma reserva para um mac. Era mais algo > num sentido geral (afinal, este tipo de verificação deveria ser feita > sempre ou na maioria dos escopos e não só no host). > > -- > GUS-BR - Grupo de Usuários de Slackware Brasil > http://www.slackwarebrasil.org/ > http://groups.google.com/group/slack-users-br > > Antes de perguntar: > http://www.istf.com.br/perguntas/ > > Para sair da lista envie um e-mail para: > [email protected]<slack-users-br%[email protected]> > > -- > GUS-BR - Grupo de Usuários de Slackware Brasil > http://www.slackwarebrasil.org/ > http://groups.google.com/group/slack-users-br > > Antes de perguntar: > http://www.istf.com.br/perguntas/ > > Para sair da lista envie um e-mail para: > [email protected]<slack-users-br%[email protected]> > > > > > -- > " Eu quero saber como renomear um arquivo " ele diz. > Por favor, é dia de pagamento, não é?! Mas eu estou de bom humor. > " Claro. Basta dar 'rm' e o nome do arquivo " > " Obrigado " > > Noilson Caio T. de Araújo > Linux Professional Institute Certification > LPI000182893 > Novell Certified Linux Administrator (CLA) > 10111916 > Novell Data Center Technical Specialist > > -- > GUS-BR - Grupo de Usuários de Slackware Brasil > http://www.slackwarebrasil.org/ > http://groups.google.com/group/slack-users-br > > Antes de perguntar: > http://www.istf.com.br/perguntas/ > > Para sair da lista envie um e-mail para: > [email protected]<slack-users-br%[email protected]> > > -- > GUS-BR - Grupo de Usuários de Slackware Brasil > http://www.slackwarebrasil.org/ > http://groups.google.com/group/slack-users-br > > Antes de perguntar: > http://www.istf.com.br/perguntas/ > > Para sair da lista envie um e-mail para: > [email protected]<slack-users-br%[email protected]> > -- " Eu quero saber como renomear um arquivo " ele diz. Por favor, é dia de pagamento, não é?! Mas eu estou de bom humor. " Claro. Basta dar 'rm' e o nome do arquivo " " Obrigado " Noilson Caio T. de Araújo Linux Professional Institute Certification LPI000182893 Novell Certified Linux Administrator (CLA) 10111916 Novell Data Center Technical Specialist -- GUS-BR - Grupo de Usuários de Slackware Brasil http://www.slackwarebrasil.org/ http://groups.google.com/group/slack-users-br Antes de perguntar: http://www.istf.com.br/perguntas/ Para sair da lista envie um e-mail para: [email protected]
