O único que entendeu o que eu realmente quis dizer foi o Daniel Junior. Eu nao disse que o lease alto é uma vulnerabilidade... Se fosse assim, o dhcp seria muito vulnerável, pois apenas um parâmetro do protocolo iria comprometer todo ele. Eu falei no sentido de que com o lease time alto, o atacante poderia ter mais tempo de realizar uma análise mais aprofundada da rede, utilizando sniffers, exploits, invadir máquinas e instalar backdoors, roubar informações pessoais (de valor ou não). Sobre o que diz a RFC, eu não tô muito por dentro, pois meu tempo (nem minha paciência, pois já li algumas e são extremamente chatas de se ler) não anda permitindo muito. E para informação do Max Miorim, realmente a maioria das redes wireless não possui controle nenhum. Muitas ainda utilizam WEP e a senha é fraquíssima, como do tipo "123456...". Muitos APs e routers ainda possuem usuário e senha padrão. Então, uma vez dentro, fica mais fácil ainda ganhar acesso à esses equipamentos. Não sei vocês, mas como gosto muito de segurança da informação, as vezes me torno meio paranóico com relação a isso. Se eu for montar uma rede wireless e tiver acesso a uma infraestrutura razoavel, eu colocaria autenticação cabeada e um servidor RADIUS, dhcp amarrado por MAC, número limitado no spool de IPs... E creio que ainda assim não estaria um nível de segurança adequado. Lógico que montar uma infra dessas vai depender tambem da sensibilidade das informações que trafegaram na rede... As vezes nao compensa tanto investimento. No mais, creio que o rapaz da rede wireless já possui algumas informações de por onde começar...
On Nov 17, 12:34 pm, Max Miorim <[email protected]> wrote: > 2010/11/17 Daniel Junior <[email protected]>: > > > Concordo com Miorim , mas acho que a questão do lease alto que o > > Oswaldo cita é que, se alguém tiver acesso a sua rede > > ele pode identificar melhor as maquinas. Pois elas demorariam mudar de > > IP. Isso dá tempo para ele conheçer melhor as falhas de cada maquina. > > É um bom ponto, mas o trecho da RFC que eu colei no email anterior diz > que os clientes podem (não siginifica que todos devem) renovar o > lease. E isso acontece com o dhcp-client e o dhcpd e provavelmente > outras implementações de cliente e/ou servidor DHCP. > > Eu acho que voces estão assumindo que quando expira o lease time, o > cliente perde o IP mas a mesma RFC2131 diz que os servidores deveriam > (no sentido de que é recomendado, não necessariamente obrigatório) > verificar se o IP já é alocado antes de liberá-lo: > > In some environments it will be necessary to reassign network > addresses due to exhaustion of available addresses. In such > environments, the allocation mechanism will reuse addresses whose > lease has expired. The server should use whatever information is > available in the configuration information repository to choose an > address to reuse. For example, the server may choose the least > recently assigned address. As a consistency check, the allocating > server SHOULD probe the reused address before allocating the address, > e.g., with an ICMP echo request, and the client SHOULD probe the > newly received address, e.g., with ARP. > > E na man page dhcpd.conf(5) diz que o ISC DHCPD faz o seguinte: > > When the DHCP server allocates a new address for a client > (remember, this only happens if the client has sent a > DHCPDISCOVER), it first looks to see if the client already has a valid > lease on an IP address, or if there is an old > IP address the client had before that hasn't yet been reassigned. > In that case, the server will take that address > and check it to see if the client is still permitted to use it. If > the client is no longer permitted to use it, the > lease is freed if the server thought it was still in use - the fact > that the client has sent a DHCPDISCOVER proves to > the server that the client is no longer using the lease. > > If no existing lease is found, or if the client is forbidden to > receive the existing lease, then the server will look > in the list of address pools for the network segment to which the > client is attached for a lease that is not in use > and that the client is permitted to have. It looks through each pool > declaration in sequence (all range declara‐ > tions that appear outside of pool declarations are grouped into a > single pool with no permit list). If the permit > list for the pool allows the client to be allocated an address from > that pool, the pool is examined to see if there > is an address available. If so, then the client is tentatively > assigned that address. Otherwise, the next pool is > tested. If no addresses are found that can be assigned to the > client, no response is sent to the client. > > If an address is found that the client is permitted to have, and that > has never been assigned to any client before, > the address is immediately allocated to the client. If the address > is available for allocation but has been previ‐ > ously assigned to a different client, the server will keep looking in > hopes of finding an address that has never > before been assigned to a client. > > > Mas mexer no lease time não é nenhuma solução de segurança efetiva. O > > lease time é mais por questão de falta > > de ips. Como a quantidade de ips para uma rede interna ainda são > > suficientes não há necessidade de um lease time muito curto. > > Isso na minha concepção só vai fazer diferença ( e muito pouca) no > > processamento do servidor. Mais nada. Um ou 2 dias, 6 horas tanto faz. > > Analise sua rede a media de computadores que irão conectar. Faça uma > > base para não sobre carregar o firewall e boa. > > É a melhor coisa que você faz. > > E outra se você quiser fazer essas alterações para segurança. E melhor > > você planejar algum tipo de autenticação. Pois amarrar ips a macs em > > um condómino onde qualquer um possa espetar um pc a qualquer momento , > > é dor de cabeça garantida. > > -- 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]
