Prezado Daniel, Quando me referi a informa��es p�blicas estava falando da rede privada de uma empresa e n�o sobre informa��es sobre invas�es, que vc est� absolutamente certo em falar que elas est�o disponiveis em varios lugares.
Em particular em todas as implanta��es que participei tanto o firewall como os roteadores de borda bloqueavam protocolos de respostas � requisi��es de nomes e ips da rede interna, ou seja para o mundo exterior a �nica m�quina visivel da rede era o firewall e roteadores que tinham ips de internet v�lido. O segundo n�vel de firewall, em geral chamado de bastian ( ou algo pareceido, n�o me lembro do nome de cabe�a ), que faz a interface entre uma rede do tipo 192, 168 ou 172 ou outras ( redes que n�o roteaveis pela internet ) e a rede intena, impedia com mecanismos de regras, filtros, etc que os ips e nomes internos sejam visiveis em quaisquer redes p�blicas como internet, mpls, frame relay, etc. Na minha opini�o a melhor solu��o � aquela que resolve o seu problema, e se a RFC + CMDB resolveu o do seu banco e muito provavelmente de outros bancos e outras empresas eu n�o d�vidas que � uma caso que deve ser publicado dentro do poss�vel, como vc fez, e estar � disposi��o de todos n�s. Na realidade o modelo que eu proponho e uso na maioria dos casos n�o � uma verdade absoluta, mas sim um modelo para ser conhecido ( alias n�o � cria��o minha ) por todos n�s e quem sabe podendo resolver um ou outro problema do mercado. Abaixo segue um trecho da RFC que vc usou e eu tb em diversos momentos, no que se refere ao que eu considero � ess�ncia dela, apenas lembrando o que � um nome f�cil para a minha empresa pode n�o ser para a sua e assim sucessivamente. Na minha vis�o mais do que falamos que a solu��o A, B ou C � a melhor devemos assumir que todas elas resolvem os problemas de uma forma ou de outra e que a oportunidade de conhecer o seu modelo para mim � uma oportunidade �nica e importante. _______________________________________________________________ RFC 1178 http://rfc.sunsite.dk Most people don't have the opportunity to name more than one or two computers, while site administrators name large numbers of them. By choosing a name wisely, both user and administrator will have an easier time of remembering, discussing and typing the names of their computers. Ricardo Mansur Gestor Tecnologia Carreira desenvolvida na gest�o das �reas de TI / Telecom. MBA em TI / Telecom e Neg�cios da Era Digital, mestrado em Finan�as e Administra��o e Engenheiro Eletr�nico. Ingles, Franc�s e Espanhol. [EMAIL PROTECTED] ----- Original Message ----- From: Daniel Checchia To: [email protected] Sent: Wednesday, May 18, 2005 10:33 AM Subject: Re: [itsm_br] Ativos Neste ponto sou obrigado a discordar parcialmente :-) Hoje o acesso � informa��o est� em v�rias revistas e na internet, possibilitando que um usu�rio de sua rede interna explore vulnerabilidades e o padr�o de nomes adotado facilita a identifica��o do servi�o que est� rodando no equipamento. Atuo em uma Institui��o financeira como coordenador de infra-estrutura e redes, sendo o respons�vel pela seguran�a de meus ativos. Para solucionar o problema de identifica��o de servidores, partimos para a montagem de um CMDB via WEB, com v�rios �ndices de busca poss�vel e padronizamos os nomes das m�quinas seguindo a RFC 1178. Esta RFC � usada, hoje, por muitas empresas, provedores de internet e Bancos, sendo (no meu ponto de vista) a solu��o ideal (RFC + CMDB). A segunda atua��o foi a segrega��o da rede com firewall interno, segregando fisicamente os ambientes de produ��o, homologa��o, desenvolvimento e os usu�rios. Cada um com seu pr�prio barramento de rede no firewall. Cordialmente, Daniel Checchia Em 16/05/05, Ricardo Mansur <[EMAIL PROTECTED]> escreveu: > > Prezado Wagner Elias, > > Em particular eu n�o creio que os nomes de servidores sejam uma > vulnerabilidade releveante, uma que que as informa��es n�o s�o publicas e > portanto os filtros nos roteadores de borda seriam os meios eficientes para > n�o divulgar os pacotes com nomes em redes p�blicas, alias qualquer que seja > o nome estes filtros devem existir. > > Se por ventura um hacker invadir uma rede � porque existem falhas de > vulnerabilidade muito maiores e graves do que nomenclaturas de nomes, > quaisquer que elas sejam. > [Non-text portions of this message have been removed] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Lista ITSM_BR - Gest�o de TI - Mantida e moderada por Gilberto Biasoto - IT Designers - http://www.ITdesigners.com.br - ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Para de descadastrar envie email para: [EMAIL PROTECTED] --- ------------------------------------------------------------------------------ Yahoo! Groups Links a.. To visit your group on the web, go to: http://groups.yahoo.com/group/itsm_br/ b.. To unsubscribe from this group, send an email to: [EMAIL PROTECTED] c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Lista ITSM_BR - Gest�o de TI - Mantida e moderada por Gilberto Biasoto - IT Designers - http://www.ITdesigners.com.br - ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Para de descadastrar envie email para: [EMAIL PROTECTED] --- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/itsm_br/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
