NAT (Network Address Translation) III

Na segunda parte desta artigo falamos sobre os elementos da rede NAT identificados como Inside. Repare na figura abaixo:

Imaginemos que o dispositivo Inside Local com endereço 10.2.2.8 quer enviar um pacote ao servidor 199.19.9.10. O pacote quando chega ao roteador RT001, este verifica na sua tabela NAT se existe uma tradução estatica ja configurada, do tipo:

Inside Local Address Inside Global Address
10.2.2.8 200.230.207.2

Se existe então o roteador RT001 remove do cabeçalho o endereço IP Inside Local 10.2.2.8 de origem e adiciona o endereço IP Inside Global 200.230.207.2 e encaminha o pacote ao destino Outside Global 199.19.9.10.

Se nao existe uma tradução estatica, então o roteador RT001 trata de adicionar uma entrada a tabela NAT (como a de cima) e de seguida encaminha o pacote ao destino Outside Global 199.19.9.10.

Quando o host 199.19.9.10 desejar enviar um pacote ao host Inside Local 10.2.2.8, ele utiliza o endereço Inside Global 200.230.207.2 e daí o pacote chega ao roteador RT001. O roteador RT001 consulta a sua tabela NAT para verificar se existe uma entrada que relaciona o endereço Inside Global 200.230.207.2 ao endereço Inside Local 10.2.2.8. Se existe uma entrada que verifique a condição o pacote é encaminhado ao endereço Inside Local 10.2.2.8.

Anúncios

NAT (Network Address Translation) II

Na primeira parte foi dada uma introduçao ao NAT e aos seus tipos. A Cisco define os dispositivos dentro duma rede NAT como pertencentes a Inside (dentro) ou Outside (fora). Como o processo NAT consiste em traduzir endereços isto significa que os endereços privados serão traduzidos em endereço(s) publicos antes de sairem da rede interna, porque como dissemos endereços privados nao podem ser roteados, então sao necessarios endereços publicos e o NAT encarrega de criar tabelas de tradução tal que um pacote com endereço de origem pertencente a rede local seja roteavel por um endereço publico.

Mas, vamos por parte. Os elementos da rede pertencentes a Inside sao divididos em Inside Local e Inside Global.

Inside Local – Todo dispositivo na rede local sujeito a tradução e que possua um endereço privado.
Inside Global – Endereço publico que fará a tradução dos pacotes vindos de endereços privados.

Os elementos da rede pertencentes a Outside sao divididos em Outside Local e Outside Global.

Outside Local – Todo dispositivo local pertencente a Outside.
Outside Global – Endereço publico de Outside que faz a tradução de pacotes vindos de endereços privados de Outside.

Pela figura:

No diagrama acima a zona Inside Local é composta pelos endereços privados por detras do Router (192.168.100.100 e 192.168.100.1).

A zona Inside Global é composta pelo endereço publico da interface S0 (no link ponto a ponto) que é 200.200.200.1.

No proximo artigo daremos continuação abordando os endereços Outside.

NAT (Network Address Translation) I

Com o objectivo de se poupar espaço de endereçamento para se diminuir o rápido esgotamento de endereços publicos inumeras tecnicas foram criadas e uma delas é a tradução de endereços de rede. O seu funciomanento aproveita-se do facto de estarem definidos um 3 conjuntos de endereços de classe A, B e C considerados privados, e sao privados por nao serem roteaveis na Internet.

Deste modo é possivel atribuir a redes locais tal conjunto de endereços descartanto assim o uso de endereços atribuidos por entidades como AfriNIC ou IANA.

Por outro lado, também urge salientar a sua grande utilidade em questões de segurança. Se estes endereços nao sao roteaveis na Internet quer dizer então que nao podem ser atacados a partir da Internet e neste caso por exemplo, pela logica, Worms nao atingem hosts endereços privados. Bom isso é um assunto em discussão.

A Cisco (sim, NAT também o possuem servidores Windows e *.Nix) implementa NAT no Cisco IOS, e por isso definiu os seguintes tipos de NAT:

Nat Estatico – Aqui um pacote vindo de um endereço local é traduzido para um endereço publico ou global que seja valido, claro, roteavel na Internet.

Nat Dinamico – Aqui um pacote vindo de um ou varios endereços locais é traduzido para uma pool (conjunto) de endereços globais e roteaveis.

Overload (PAT) – Aqui um pacote vindo de um ou varios endereços locais é traduzido para um unico endereço global. Este tipo de NAT é também conhecido como Port Address Translation, visto que o endereço global ou roteavel usa um conjunto de canais ou portas para encaminhar os pacotes locais para a Internet.

No proximo artigo veremos como se definem os dispositivos NAT na rede.

Criando listas de controlo de acesso (ACL). Parte II

No nosso primeiro artigo introduzimos conceitos basicos sobre acls bem como a sintaxe básica de acls padrão e estendidas. A melhor forma de perceber o funcionamento duma ACL é com um diagrama:

No primeiro exemplo pede-se para escrever uma lista de acesso padrão que negue acesso a rede 10.1.1.0 que está no roteador B mas permita todos outros acessos.

Existe uma regra básica quando se vai fazer uma acl padrão: Ela deve ser aplicada mais proximo do destino dos pacotes.

No nosso caso estamos interessados em que se barre o acesso a essa rede (10.1.1.0) a partir do roteador A, mas que se permita todos outros acessos, por exemplo a rede 10.2.1.0 ou a rede da Microsoft:

Router(config)#access-list 14 deny 10.1.1.0 0.0.0.15
Router(config)#access-list 14 permit any

A instrução permity any é importante e deve ser aplicada sob pena de se barrar todo acesso a qualquer outra rede, já que no fim de cada acl existe uma instrução implicita deny any.

É necessario agora aplica-la a uma interface que no nossa caso será a serial do roteador A (origem). A direcção será a de entrada dos pacotes no roteador (inbound). Desta forma os pacotes que entram no roteador e sao roteaveis e que forem dirigidos a rede 10.1.1.0 serão descartados pela verificação da acl. Se não, serão encaminhados:

Router(config)#interface serial 0/3/0
Router(config-if)#ip access-group 14 in

Para desassociar uma determinada acl a uma interface basta negar o comando anterior:

Router(config)#interface serial 0/3/0
Router(config-if)#no ip access-group 14 in

Um outro exemplo: crie uma lista de acesso estendida que negue telnet para a rede da interface loopback 0 a partir de qualquer origem, mas o telnet e qualquer outro tráfego a partir de qualquer outro endereço ip ou rede ou para qualquer outra rede deverá funcionar.

Esta lista deverá ser aplicada na interface serial do roteador A. Sabemos que as listas de acesso estendidas devem estar mais proximas da origem dos pacotes.

Router(config)#access-list 103 deny tcp any 192.168.1.0 0.0.0.63 eq 23
Router(config)#access-list 103 permit ip any any

A instrução any é semelhante a instrução

0.0.0.0 255.255.255.255. Sabemos que 0.0.0.0 é encarada pelo roteador como uma rota default. Com uma mascara de sub-rede 0.0.0.0 e mascara curinga será 255.255.255.255. Entao a lista acima poderia ser escrita como:

Router(config)#access-list 103 deny tcp 0.0.0.0 255.255.255.255 192.168.1.0 0.0.0.63 eq 23
Router(config)#access-list 103 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

Basta agora aplica-la na interface na direcção inbound.

Router(config)#interface serial 0/3/0
Router(config-if)#ip access-group 103 in

Mas repare numa situação: Se quisessemos barrar TFTP? A lista acima seria da seguinte forma:

Router(config)#access-list 103 deny udp any 192.168.1.0 0.0.0.63 eq 69
Router(config)#access-list 103 permit ip any any

Imagine que quisessemos barrar pings a partir de qualquer origem? Como sabemos ele utiliza o protocolo icmp:

Router(config)#access-list 104 deny icmp any 192.168.1.0 0.0.0.63
Router(config)#access-list 104 permit ip any any
Router(config)#interface serial 0/3/0
Router(config-if)#ip access-group 104 in

Um pequeno teste:

PC>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Se notou acima viu que uma das desvantagens das ACL padrão é que ela barra todos os protocolos da stack TCP/IP e nao permite barrar também determinados portos, daí então que as ACL estendidas sao a melhor opção quando se pretende maior flexibilidade nas operações.

Criando listas de controlo de acesso (ACL). Parte I

Listas de controlo de acesso, existem em diversas plataformas e sistemas. No nosso caso vamos falar de ACLs em roteadores Cisco.

Uma ACL pode ser definida como um classificador de pacotes. Essa classificação pode ser depois aplicada nao apenas na filtragem de pacotes, mas na encriptação, na qualidade de serviço (QoS), NAT, PAT, DDR etc.

Existem 2 tipos de ACL no cisco IOS: Padrão e estendidas sao as mais usadas. Outros tipos sao as reflexivas, as time-based e as dinamiscas (lock and key).

As ACL padrão sao aquelas que identificam o endereço de origem do pacote e tomam uma decisao de permissao ou negação.
As ACL estendidas sao aquelas que identificam o endereço de origem e de destino bem como protocolos, portas e outros parametros.

As ACL padrão e estendidas podem ser identificadas de 2 formas distintas: Por um intervalo de numeros ou por nome. Sendo assim por numeros, as ACL padrão sao identificadas por 1 a 99 e 1300 a 1999. As ACL estendidas sao identificadas pelos numeros de 100 a 199 e 2000 a 2699.

Por outro lado uma ACL pode também ser identificada por um conjunto de caracteres alfanumericos (string). Isto por vezes facilita bastante na edição ou identificação ou atribuição nas interfaces.

As ACL devem ser implementadas em interfaces e uma interface pode ter varias ACL, mas Somente uma ACL por protocolo, por direcção e claro por interface.

O protocolo pode ser qualquer um pertencente a camada de rede. TCP, UDP ou mesmo ICMP sao válidos. A direcção pode ser inbound (entrada de pacote no roteador) ou outbound (saída de um pacote no roteador).

As vezes é dificil entender a operação de ACLs porque nao se presta atenção a um aspecto muito importante: A sinaxe do comando e o entendimento dos seus parametros.

As listas de acesso padrão possuem o seguinte formato:

access-list access-list-number {deny | permit} source source-wildcard

access-list-number – Numero que pode ser e 1 a 99 ou de 1300 a 1999.
deny                              – Rejeita.
permit                          – Permite.
source                          – Rede, subrede ou host onde o pacote tem origem.
source-wildcard      – A mascara curinga, que identifica que endereços de origem (intervalo) serão classificados.

As listas de acesso estendidas possuem o seguinte formato:

access-list access-list-number {permit | deny} protocol source source-wildcard [operator port] destination destination-wildcard [operator port] [established] [log]

access-list-number – Numero que pode ser e 100 a 199 ou de 2000 a 2699.
deny                              – Rejeita.
permit                          – Permite.
source                          – Rede, subrede ou host onde o pacote tem origem.
source-wildcard       – A mascara curinga, que identifica que endereços de origem (intervalo) serão classificados.
operator                      – serve para identificar as portas e pode ser um dos seguintes: eq (equal), neq (not equal), range (intervalo), lt (lower than), gt (greater than).
port                               – O porto de saída ou entrada (canal) do pacote da rede de origem ou da rede de destino. Muitas destas portas pertencem ou ao sub-protocolo TCP ou ao UDP. Alguns destes protocolos sao o telnet  (23), ftp (20 e 21), smtp (25), http (80).
destination                 – Rede de destino dos pacotes.
destination-wildcard – A mascara curinga que identifica que endereços de destino (intervalo) serão classificados.

Os parametros established e log serão tratados na segunda parte deste artigo que trará, já exemplos práticos.

Como ser o vale do Silicio? Paul Graham, sabe

Paul Graham é considerado por muitos como um dos melhores programadores do mundo. Versado em LISP (no makarenko tentei usar CAD com LISP e desenconrajei-me logo) que usou para criar o sistema que foi usado pelo antigo Yahoo Store. Foi também pioneiro na luta contra o SPAM ao sugerir o uso de filtros ‘bayesianos’, além de escrever varios livros sobre computação e criar uma nova linguagem de programação.

Com tantas ideias, Paul as vezes escreve também sobre alguns assuntos interessantes. Um deles é a tentativa de se criarem fábricas de software, ‘similitudes’ tipo vale do silicio (Sillicon Valley) em varias partes do mundo e todas elas falharam, e Paul Graham diz porque isso aconteceu nestes excertos:

Dois Tipos

O necessário são as pessoas certas. Se você pudesse fazer com que as dez mil pessoas certas se mudassem do Vale do Silício para Buffalo, Buffalo se tornaria o Vale do Silício.

Eu [Paul] acredito que só se precisa de dois tipos de pessoas para criar um hub tecnológico: pessoas ricas e nerds. Estes são os reagentes na reação que produz empresas startup, pois são os únicos presentes quando startups são iniciadas. Todo mundo mais vai se mudar.

Observações suportam isto: dentro dos EUA, cidades se tornaram pólos de startups  se, e somente se, elas tinham tanto pessoas ricas quanto nerds. Poucas startups  “acontecem” em Miami, por exemplo, pois embora ela esteja cheia de pessoas ricas, tem poucos nerds. Miami não é o tipo de lugar que nerds gostam.

Não Burocratas

As pessoas ricas são realmente necessárias? Não funcionaria se o governo investisse nos nerds? Não, não iria funcionar. Investidores em startups  são um tipo diferente de pessoas ricas. Eles tendem a ter muita experiência própria em negócios envolvendo tecnologia. Isto (a) ajuda-os a escolher as startups certas e (b) significa que eles podem fornecer conselhos e conexões além de dinheiro. E o fato de que eles têm algo pessoal em jogo faz com que eles realmente prestem atenção.

Não Prédios/Construções

Construir prédios de escritórios para empresas de tecnologia não vai te dar um Vale do Silício, pois o estágio chave na vida de uma startup  acontece antes que elas queiram esse tipo de espaço. O estágio chave é quando são três caras operando a partir de um apartamento. Onde quer que a startup seja quando ela receber investimento, ela vai ficar. A qualidade que define o Vale do Silício não é que a Intel, a Apple ou o Google tem escritórios lá, mas sim que elas foram criadas  lá.

Então, se você quer reproduzir o Vale do Silício, o que você tem que reproduzir são aqueles dois ou três fundadores sentados ao redor de uma mesa de cozinha decidindo começar uma empresa. E para reproduzir isso você precisa daquelas pessoas.

Universidades

O interessante é que tudo que se precisa são as pessoas. Se você pudesse atrair uma massa crítica de nerds e investidores para morar em algum lugar, você poderia reproduzir o Vale do Silício.

Então se você quiser fazer um Vale do Silício, você não precisa apenas de uma universidade, mas uma das poucas top do mundo. Ela tem que ser boa o suficiente para funcionar como um imã, atraindo as melhores pessoas de milhares de quilômetros de distância. E isto significa ter que concorrer com imãs já existentes como o MIT ou Stanford.

Personalidade

No entanto, meramente criar uma nova universidade não seria suficiente para começar um Vale do Silício. A universidade é apenas a semente. Ela tem que ser plantada no solo certo, ou ela não germinará. Plante-a no lugar errado e você acaba criando uma Carnegie-Mellon.

Para fazer brotar startups, sua universidade tem que estar numa cidade que tenha outras atrações além da universidade. Tem que ser em um lugar onde os investidores queiram viver e onde os estudantes queiram ficar depois que se graduem.

Nerds

Se você quer atrair nerds, você precisa de mais que uma cidade com personalidade. Você precisa de uma cidade com a personalidade certa. Nerds são um subconjunto distinto da classe criativa, com gostos diferentes do resto. Você pode ver isso claramente em Nova York, a qual atrai muitas pessoas criativas, mas poucos nerds.

Tempo

Isto tem duas importantes implicações. A primeira é que você precisa de tempo para “crescer” um Vale do Silício. A universidade você poderia criar em alguns poucos anos, mas a comunidade startup ao redor teria que crescer organicamente. O tempo do ciclo é limitado pelo tempo que leva para uma empresa ter sucesso, o que provavelmente leva cerca de cinco anos.

Competição

Claro, um possível Vale do Silício enfrenta um obstáculo que o original não tinha: ele tem que competir com o Vale do Silício. Isso pode ser feito? Provavelmente.

Tais forças centralizadoras tornam mais difícil começar novos Vales do Silício. Mas de maneira nenhuma impossível. No fim das contas, o poder está com os fundadores. Uma startup  com as melhores pessoas vai bater uma com fundos de VCs famosos, e uma startup que seja suficientemente de sucesso nunca precisaria se mudar. Sendo assim, uma cidade que pudesse exercer uma força suficiente sobre as pessoas certas poderia resistir e talvez até suplantar o Vale do Silício.

Você pode encontrar o artigo completo traduzido para o Portugues, aqui: