DHCP Tempo de expiração
Thiago Gomes
atribuição atraves de dhcp.. gostaria saber da opinião
de vocês sobre o tempo de expiração para os ip.. fiz a configuração de
1 dia é pouco ?? o que acham ??
--
Thiago Gomes
Max Miorim
IIRC os clientes vão se renovar até não querer mais, eu já vi
computadores renovarem o lease por mais de um ano. Então, que
diferença faz? :)
Noilson Caio
Se tiver uma classe de IP limitada, número de hosts quase com o mesmo valor de ips válidos da classe;
Rotatividade de hosts; Exemplos, um shopping center, não precisar ter um lease longo; 3 horas, tá massa.
Bem, são alguns dos detalhes.
--
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:
slack-users-b...@googlegroups.com
--
" 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
http://ncaio.ithub.com.br
Psycho Mantys
Acho que ta bom.
:]
--
Mi blog eres su blog: https://www.lccv.ufal.br/~psycho/
@psycho_mantys : http://twitter.com/psycho_mantys
http://www.slackware.com
U.L. : 450347
Fnord
Max Miorim
> Vários fatores serão relevantes:
> Se tiver uma classe de IP limitada, número de hosts quase com o mesmo valor
> de ips válidos da classe;
> Rotatividade de hosts; Exemplos, um shopping center, não precisar ter um
> lease longo; 3 horas, tá massa.
> Bem, são alguns dos detalhes.
Sim, se tu tem um /24 e mais clientes que o /24 eu entendo, mas este
parece um caso óbvio que não faz a menor diferença porque ele usa uma
rede privada e dificilmente vai superar o limite de hosts desta rede
privada (se o /24 não for suficiente, tem um /16 ou /8).
A questão da rotatividade também depende do numero de hosts, se tu tem
mais endereços do que gente pedindo, não vai ter rotatividade, por
mais que configure para tanto. Eu conheço alguns bares que dão um /8
com um lease de 6 horas e eu pego o mesmo endereço por semanas no meu
telefone.
Enfim, o caso dele não parece sofrer da restrição de hosts x ips
disponíveis, ainda me parece um caso que não faz diferença alguma.
Noilson Caio
--
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:
slack-users-b...@googlegroups.com
««®ätö/|/|äñ.ëxë»»
Osvaldo Filho
O que realmente você busca?
Porque como é um condominio, creio que a área de alcance deve ser
razoavel.
Se voce deixar um lease time muito grande, dará tempo de alguém tentar
inúmeros ataques, haja vista que nao creio que haverá ninguém
monitorando a rede.
Eu só colocaria um lease time superior a um dia se eu utilizasse dhcp
estático, amarrado por MAC. Mesmo um dia ainda é um tempo muito grande
para que um atacante possa explorar sua rede.
Conheço vários amigos que moram em condominios ou moram próximo e que
se utilizam dessas brechas e não pagam pela conexão. Simplesmente
utilizam de grátis...
Fica a dica!
On 16 nov, 16:01, ««®ätö/|/|äñ.ëxë»» <ratoman....@gmail.com> wrote:
> Eu acho que uns 7 dias tá bom. Se for condomínio não deve ter muita
> rotatividade.
>
>
>
>
>
>
>
>
>
>
> > ok
>
>
> > 2010/11/16 Noilson Caio <caiog...@gmail.com>:
> > --
> > " 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
> >http://ncaio.ithub.com.br
>
> > --
> > 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:
««®ätö/|/|äñ.ëxë»»
Max Miorim
> Depende.
> O que realmente você busca?
> Porque como é um condominio, creio que a área de alcance deve ser
> razoavel.
> Se voce deixar um lease time muito grande, dará tempo de alguém tentar
> inúmeros ataques, haja vista que nao creio que haverá ninguém
> monitorando a rede.
> Eu só colocaria um lease time superior a um dia se eu utilizasse dhcp
> estático, amarrado por MAC. Mesmo um dia ainda é um tempo muito grande
> para que um atacante possa explorar sua rede.
> Conheço vários amigos que moram em condominios ou moram próximo e que
> se utilizam dessas brechas e não pagam pela conexão. Simplesmente
> utilizam de grátis...
> Fica a dica!
Eu não consigo entender qual a "vulnerabilidade" de ter um lease alto.
O lease time não tem nada a ver com o problema que tu descreve. O
problema é que tu assume que tem uma rede wireless que não tem nenhum
mecanismo de autenticação/autorização e qualquer um conecta.
Neste caso, tanto faz lease time de uma hora ou um ano: o cliente
continua com o IP enquanto não der o release e como a rede é aberta, é
só ele fazer o request denovo e continuar usando. A própria RFC2131
diz que isto pode ser feito:
"The basic mechanism for the dynamic allocation of network addresses
is simple: a client requests the use of an address for some period of
time. The allocation mechanism (the collection of DHCP servers)
guarantees not to reallocate that address within the requested time
and attempts to return the same network address each time the client
requests an address. In this document, the period over which a
network address is allocated to a client is referred to as a "lease"
[11]. The client may extend its lease with subsequent requests. The
client may issue a message to release the address back to the server
when the client no longer needs the address. The client may ask for a
permanent assignment by asking for an infinite lease. Even when
assigning "permanent" addresses, a server may choose to give out
lengthy but non-infinite leases to allow detection of the fact that
the client has been retired."
Daniel Junior
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.
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:
> slack-users-b...@googlegroups.com
--
Att, Daniel Junior
Leonardo Vilar
--
Leonardo Vilar Tavares da Silva
Max Miorim
> 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.
Osvaldo Filho
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 <miorim...@gmail.com> wrote:
> 2010/11/17 Daniel Junior <jrdan...@gmail.com>:
««®ätö/|/|äñ.ëxë»»
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).
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.
--
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:
slack-users-b...@googlegroups.com
--
By ««®ätö/|/|äñ.ëxë»»
Max Miorim
> 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).
mandei um (na verdade dois) trecho da RFC dizendo de forma bem clara
como funciona a alocação de endereços e um trecho da documentação do
dhcpd dizendo como que a coisa é implementada na prática.
Resumindo bem, se tu usa o ISC DHCPD tanto faz se o lease é de 1 hora,
1 dia ou 1 ano, ele vai tentar alocar o mesmo IP para o mesmo cliente
se não precisar de rotatividade. Se tem uma rede /24 com 300 hosts, tu
vai ver os IPs mudando por causa da rotatividade, se tu tem uma rede
/24 para 200 hosts, não faz a menor diferença, o zezinho do 302 vai
receber o mesmo IP praticamente todos os dias porque a implementação
do dhcpd faz isso.
Sem contar que a própria RFC diz que o cliente pode dizer algo como
"meu último IP era 1.2.3.4, pode mandar ele denovo?"...
E se olhar no "atacante" que pega um IP numa rede dessas, se ele
entrou uma vez no WEP configurado pelo sobrinho do síndico, ele vai
fazer isso denovo com ainda mais facilidade e provavelmente vai
continuar pegando o mesmo IP, se não houver a rotatividade. :)
Enfim, na melhor das hipóteses, o que tu consegue é um pouco de
"security through obscurity", que é fácil de contornar com uns pings
p/ toda a rede e depois só consultar a tabela ARP p/ ver o mac da
"vítima" anterior... Quero dizer, uma vez que um invasor consegue
pegar o IP, a tua rede já está comprometida. O DHCP não é segurança,
ele não foi feito p/ isso e é por isso que existem soluções de
segurança que o _complementam_, como é o caso do RADIUS.
> 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.
A 2131 é bem curta, eu acho que o pessoal respondendo nesta thread
deveria ler. A parte da dhcpd.conf(5) que explica a implementação
também é importante, tem uma série de conceitos aqui que,
aparentemente, são de "achismo" (eu ainda acho que voces estão
pensando que quando expira um lease, o IP é automagicamente liberado e
o cliente que o detem recebe um IP na mesma hora - do ponto de vista
da segurança isso é o ideal, mas eu não conheço nenhum servidor DHCP
que implementa desta forma, referencias são bem-vindas).
> 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.
Tu fala como se eu vivesse numa bolha e não tivesse idéia da
quantidade de besteira que os "técnicos" saem fazendo por ai... Eu
acho que eu tenho que parar de falar dentro de um contexto e
generalizar sempre?
> 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...
O detalhe é que ninguém falou em rede wireless, ele só falou em
condomínio. Quem começou a trazer a história do wireless e dos
problemas de segurança de uma rede wireless mal feita foi tu. ;)
Leonardo Vilar
--
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:
slack-users-b...@googlegroups.com
--
Ellington Santos
> ei galera, quero aprender a invadir..
huauahhuahuahuahua
So o Leonardo pra aparacer com uma dessa!
Como resposta oficial: "VAI NOS MANOS DO SLACKWARE QUE ELES MANJAM!!!"
;-)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> necropresto - Slackware User <<
>> necro...@gus-br.org <<
>> necro...@gmail.com <<
Max Miorim
> 2010/11/18 Leonardo Vilar <slackwa...@gmail.com>:
>> ei galera, quero aprender a invadir..
>
> huauahhuahuahuahua
> So o Leonardo pra aparacer com uma dessa!
>
> Como resposta oficial: "VAI NOS MANOS DO SLACKWARE QUE ELES MANJAM!!!"
>
> ;-)
Os caras do slackware nao manjam nada, os caras do youtube que são os
entendidos: http://www.youtube.com/watch?v=buvjwqvY0P4
Bluesball
--
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:
slack-users-b...@googlegroups.com
--
Bluesball
_
°v°
/(S)\ SLACKWARE
^ ^ Linux
Linux User #469161
## EOF
Osvaldo Filho
Sò tentei informar ao nosso amigo algumas dicas de possiveis maneiras
de melhorar a segurança da rede dele.
Para mim, mesmo você mostrando a RFC, a RFD, RFE eu ainda acho que
pode fazer alguma diferença. Pode ser significativa? Talvez. Eu acho
que segurança nunca é demais!
E sobre o RADIUS, eu já havia falado no post anterior... O problema é
que nem sempre se dispõe de tempo$$$$ para implementar uma solução
dessas, principalmente em condomínios, onde cada um quer pagar mais
barato que o outro e querem uma conexão segura e de 10GB por 10 reais.
>O detalhe é que ninguém falou em rede wireless, ele só falou em
>condomínio. Quem começou a trazer a história do wireless e dos
>problemas de segurança de uma rede wireless mal feita foi tu. ;)
thread serve para consultas futuras e para novos integrantes que
venham a aparecer no grupo.
>Tu fala como se eu vivesse numa bolha e não tivesse idéia da
>quantidade de besteira que os "técnicos" saem fazendo por ai... Eu
>acho que eu tenho que parar de falar dentro de um contexto e
>generalizar sempre?
citou isso, quem sabe voce realmente vive? O capacete se encaixa na
cabeça de quem quer.
>A 2131 é bem curta, eu acho que o pessoal respondendo nesta thread
>deveria ler. A parte da dhcpd.conf(5) que explica a implementação
>também é importante, tem uma série de conceitos aqui que,
>aparentemente, são de "achismo" (eu ainda acho que voces estão
>pensando que quando expira um lease, o IP é automagicamente >liberado e o cliente que o detem recebe um IP na mesma hora - do >ponto de vista da segurança isso é o ideal, mas eu não conheço >nenhum servidor DHCP que implementa desta forma, referencias são >bem-vindas).
pois sempre vejo posts OFF-TOPIC. Creio que mesmo os mais novatos na
área não acham que em T.I. as coisas acontecem automagicamente. Pode
ser importante mesmo ler RFC. Mas na maioria das vezes a pessoa já
está com tanta coisa para ler que fica quase impossível ler coisas
desse tipo. É um ótimo conhecimento, mas geralmente a pessoa tem
coisas do trabalho (alguma implementação p/ fazer e tem que ler vários
HOW-TO), faculdade, certificações... Nem sempre podemos estudar apenas
o que é necessário ou o que realmente gostamos.
Creio que ninguém aqui viva de "achismo". Acho que a maioria já leu e
estudou sobre DHCP. Só que as fontes não são tão detalhistas quanto
uma RFC - que padroniza os protocolos. Daí voce querer julgar todo
mundo porque voce leu a RFC e nós não...
On Nov 18, 11:16 pm, Max Miorim <miorim...@gmail.com> wrote:
> 2010/11/18 Ellington Santos <necropre...@gmail.com>:
>
> > 2010/11/18 Leonardo Vilar <slackwarevi...@gmail.com>: