Configurando Snort e Guardian

Instalando o Snort no Debian



Snort é um "farejador" que analisa todo o tráfego da rede, porém não toma nenhuma atitude. Neste tutorial você verá como integrar o Snort com o Guardian. O Guardian, por sua vez, toma a ação de atualizar o iptables com os alertas gerados pelo Snort, ou seja, ele interpreta o log do Snort e atualiza a regra do iptables.

Antes de iniciar, vamos colocar os seguintes mirrors em nosso sources.list:


Código: Selecionar todos
deb http://ftp.us.debian.org/debian lenny main contrib non-free
deb http://de.debian.org/debian squeeze main

Agora vamos atualizar a lista de pacotes:

# apt-get update

Criar diretório IDS na raiz:

# mkdir /IDS

Criar diretório para instalação do http:

# mkdir /www

Copiar todos os pacotes para /IDS:

# cp snort-xxx.tar.gz /IDS
# cp http-xxx.tar.gz /IDS

Descompactar em /IDS e fazer a compilação:

# tar -zxvf http-xxx.tar.gz
# cd http-xxx

Obs.: Verifique se o pacote build-essential está instalado, pois utilizaremos o compilador GCC e esse pacote já vem o GCC e outros softwares. Caso não esteja devidamente instalado, utilize:

# apt-get -y install build-essential
# ./configure --prefix=/www
# make && make install

Verifique se o iptables está instalado e sua versão utilizando:

# iptables -V

Antes de instalar o Snort, vamos instalar a Libcap, que é necessária para a instalação do Snort:

# apt-cache search libpcap

(assim verificamos o nome e a versão do pacote)

# apt-get -y install libpcap0.8-dev

Foi utilizada a versão 0.8 da libpcap.

Precisamos instalar também o Libpcre:

# apt-get -y install libpcre3-dev

Agora vamos instalar o Snort-xxx:

# tar -zxvf snort-xxx.tar.gz
# cd snort-xxx
# ./configure
# make && make install

Crie os seguintes diretórios:

# mkdir /etc/snort
# mkdir /etc/snort/rules

Ainda no diretório /IDS/snort-xxx faça:

# cd etc/
# cp classification.config gen* threshold.conf unicode.map sid* snort.conf reference.config /etc/snort/

Agora vamos colocar as rules baixadas do site snort.org (lembrando que é necessário ter login no referido site para baixar as rules):

# cd /IDS
# tar -zxvf snortrules-snapshot-CURRENT.tar.gz
# cd rules
# cp * /etc/snort/rules

Obs.: O link direto para download é: snortrules-snapshot-CURRENT.tar.gz

Para isso você precisa ter login, mas para criar seu login no site é FREE, grátis. :)

Crie o arquivo que irá guardar os logs:

# mkdir /var/log/snort
# cd /var/log/snort
# touch alert

Para rodar o Snort, edite o arquivo:

# vim /etc/snort/snort.conf

Altere a linha:

var RULE_PATH ../rules

Para:

var RULE_PATH /etc/snort/rules

E faça assim:

# snort -c /etc/snort/snort.conf -o

Ou melhor:

# snort -c /etc/snort/snort.conf -o -i eth0 -D


Definição do Guardian:


"O Guardian, é uma ferramenta que lê os logs do snort em tempo real e bloqueia algum ataque que esteja vindo de algum lugar na internet, ou melhor, bloqueia alguma coisa que possa vir a ser um problema para seu servidor e/ou você." - Snort + MySQL + Guardian + ACID - ataliba.eti.br

Agora vamos instalar o Guardian:

# cd /IDS
# tar -zxvf guardian-1.7.tar.gz
# cd guardian-1.7/scripts

O programa Guardian utiliza sempre os scripts denominados guardian_block.sh e guardian_unblock.sh. Assim, deverão ser copiados para os arquivos com esses nomes correspondentes ao firewall que pretendemos utilizar. Copie:

# cp iptables_block.sh /usr/bin/guardian_block.sh
# cp iptables_unblock.sh /usr/bin/guardian_unblock.sh
# chmod 755 /usr/bin/guardian_block.sh /usr/bin/guardian_unblock.sh
# cd ..
# cp guardian.pl /usr/bin
# chmod 755 /usr/bin/guardian.pl
# cp guardian.conf /etc/

Vamos configurar alguns parâmetros no guardian.conf:

Interface eth0 #Interface eth0, a que terá os terminais bloqueados
AlertFile /var/adm/secure #Mude para /var/log/snort/alert
TimeLimit 86400 #Mude para um valor em segundos que pretendemos que o endereço IP fique bloqueado pela firewall. O valor 99999999 remove esta opção.

Crie o arquivo de log do guardian:

# touch /var/log/guardian.log

Crie o arquivo guardian.ignore com os endereços IP que se pretende ignorar:

# touch /etc/guardian.ignore

Inicie o Guardian:

# guardian.pl -c /etc/guardian.conf

Caso retorne um erro relacionado a seu IP, ex.:

Warning! HostIpAddr undefined!
Attempting to guess...

Abra o arquivo /etc/guardian.conf, no começo do arquivo, descomente a linha:

# HostIpAddr

Deixando assim:

HostIpAddr SEUIP

Ex.: HostIpAddr 192.168.0.102

Agora, tente de novo iniciar o Guardian...

Para visualizar o log use:

# tail -f /var/log/snort/alert

Uma observação importante é que o Snort, com o pacote básico das regras, gera muitos falsos positivos, porém serve muito bem! Exstem também regras para serem compradas prontas, oque geraria um maior nivel de precisão.


Fonte: VOL

Testando o Wireshark

Ambiente de Teste:

- Configurar o Servidor Debian com duas interfaces de rede:
1) nat
2) interna

- Configurar o cliente com interface gráfica com uma interface
de rede (interna)

- Instalar o sniffer no cliente:

apt-get install wireshark

- executar no terminal:

sudo wireshark

- selecionar a interface eth0 para captura

- instalar servidor de ftp no servidor:

apt-get install proftpd

- através do cliente conectar no servidor de ftp:

ex.: no terminal digitar:

ftp 192.168.0.1 (ip do servidor)
-digitar um usuário e senha válidos
-comandos disponíveis (dir, quit, etc.)

- parar a captura no wireshark e analisar os
pacotes FTP (capturar usuário e senha)
- a partir do terminal do cliente executar o
comando ping para alguns sites e capturar os pacotes

Configuração de interfaces do servidor:
Virtualbox (1-NAT, 2-INTERNA)

editar /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

Configuração de interfaces do cliente:
virtualbox (1-INTERNA)

editar /etc/network/interfaces

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

adicionar a rota default no cliente:

route add default gw 192.168.1.1


No Servidor (ativar roteamento e ativar mascaramento de ip para
a rede do cliente)

Para manter as configurações deve-se editar o arquivo
/etc/rc.local
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 0/0 -p all
-j MASQUERADE

Criando VPN com o OpenVPN

Neste artigo traremos passo a passo como criar sua VPN com o OpenVPN:
O pacote necessario e o openvpn, em distribuicoes como
debian, basta usar o apt e instalar o pacote.
-> apt-get install openvpn
Apos instalado o pacote, certificar de que o modulo
tun esteja carregado, se nao estiver, use o comando
abaixo para poder carrega-lo.
-> modprobe tun
Depois de instalado e o modulo carregado, comecaremos a configurar
a vpn. Para este exemplo, usaremos os nomes de matriz e filial
por questao de definicao,
-> O diretorio padrao de trabalho e: /etc/openvpn/
O primeiro passo a ser feito, e gerar a chave de encriptacao
no roteador da matriz, com o comando, isso ira gerar um arquivo
com o nome de vpnkey e a key dentro dele:
-> openvpn –genkey –secret vpnkey
-Configuracao de rede na matriz:
*Exemplo de configuracao no roteador da matriz:
eth0: 200.10.10.1
eth1: 192.168.0.1
-Configuracao de rede na Filial:
eth0: 230.110.10.34
eth1: 192.168.1.1
Iremos criar agora os arquivos de configuracoes da filial, no
roteador da matriz e daremos o nome ao arquivo de filial.conf
——————-filial.conf——————————–
# Usa o modulo de interface tun carregado anteriormente
dev tun
# Ip remoto a conectar (No caso o ip da Matriz)
remote 200.10.10.1
# Primeiro ip local tunelado(filial) e segundo ip tunelado Matriz.
ifconfig 10.0.0.1 10.0.0.2
# Arquivo que contem a chave.
secret vpnkey
# Porta UDP que sera usada pelo VPN
# Mais de 1 VPN tera que usar portas difirentes
# esta porta fica a mesma na matriz e na filial
port 5003
# Testa a conexao do VPN
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key# Verbosity level.
# 0 — quiet except for fatal errors.
# 1 — mostly quiet, but display non-fatal network errors.
# 3 — medium output, good for normal operation.
# 9 — verbose, good for troubleshooting
verb 3
# Scripts a serem rodados quando o vpn for ativado
# e quando o vpn for desativado
up /etc/openvpn/filial.up
down /etc/openvpn/filial.down
- Agora iremos criar o arquivo filial.up que colocara as rotas para nosso vpn com a filial.
#!/bin/sh
echo
echo “Criando rotas para redes tuneladas…”
ip route add 192.168.0.0/24 via 10.0.0.2
touch /etc/openvpn/up.running
- Agora iremos criar o arquivo filial.down que ira retirar as rotas para nosso vpn com a filial.
#!/bin/sh
echo
echo “Removendo rotas para redes tuneladas…”
ip route del 192.168.0.0/24 via 10.0.0.2
touch /etc/openvpn/down.running
PRONTO!! As configuracoes do vpn na matriz ja esta certa, vamos agora
para o roteador da filial configura-lo.
-Com os mesmos pacotes e modulos carregados..
1- Copie o arquivo vpnkey que voce gerou no rotedor da matriz e coloque
dentro da pasta /etc/openvpn no roteador da filial.
2- Crie os arquivos abaixo(parecido com os que voce criou na matriz).
——————-matriz.conf——————————–
# Usa o modulo de interface tun carregado anteriormente
dev tun
# Ip remoto a conectar (No caso o ip da Filial)
remote 230.110.10.34
# Primeiro ip local tunelado(Matriz) e segundo ip tunelado filial.
ifconfig 10.0.0.2 10.0.0.1
# Arquivo que contem a chave.
secret vpnkey
# Porta UDP que sera usada pelo VPN
# Mais de 1 VPN tera que usar portas difirentes
# esta porta fica a mesma na matriz e na filial
port 5003
# Testa a conexao do VPN
ping 15
ping-restart 45
ping-timer-rempersist-tun
persist-key
# Verbosity level.
# 0 — quiet except for fatal errors.
# 1 — mostly quiet, but display non-fatal network errors.
# 3 — medium output, good for normal operation.
# 9 — verbose, good for troubleshooting
verb 3
# Scripts a serem rodados quando o vpn for ativado
# e quando o vpn for desativado
up /etc/openvpn/matriz.up
down /etc/openvpn/matriz.down
- Agora iremos criar o arquivo matriz.up que colocara as rotas para nosso vpn com a filial.
#!/bin/sh
echo
echo “Criando rotas para redes tuneladas…”
ip route add 192.168.1.0/24 via 10.0.0.1
touch /etc/openvpn/up.running
- Agora iremos criar o arquivo matriz.down que ira retirar as rotas para nosso vpn com a filial.
#!/bin/sh
echo
echo “Removendo rotas para redes tuneladas…”
ip route del 192.168.1.0/24 via 10.0.0.1
touch /etc/openvpn/down.running
PRONTO!!
Inicie o openvpn tanto na matriz quando na filial.
/etc/init.d/openvnp start

Usando o comando wget no Windows

Muitos gostam de usar o comando wget, com seus infinitos recursos. Veremos como usá-lo no windows

Bem em seu pacote original http://www.gnu.org/software/wget/
Seu código pode ser baixado aqui http://ftp.gnu.org/gnu/wget/

Os que são programadores podem compilar suas próprias versões, usando Visual Studio C da Microsoft, ou o da Borland. Dentro da pasta windows do seu código tem um arquivo README que explica mais detalhes.

Bem existe nesse site http://users.ugent.be/~bpuype/wget/ uma versão já compilada.
Vamos abrir o cmd . Em inicia > executar : comando cmd
Pode-se salvar esse executavel no G:isos.
Para entrar na pasta digitei
g:

Depois

cd isos

Para poder executar o binário. Para executar o programa:

wget website/arquivo

Foi usado o comando que lê o conteúdo de um arquivo com links,
a opção -c continua o download se houver algum problema
e a opção i para ler o arquivo chamado mandriva:
wget -ci  mandriva

Baixando o kubuntu

wget -c http://ubuntu.c3sl.ufpr.br/releases/kubuntu/karmic/
kubuntu-9.10-desktop-i386.iso

A tela do comando no Windows ,nesse caso baixando o dvd do mandriva:

Extraído de: http://www.oficinadanet.com.br/artigo/windows/usando_o_comando_wget_no_windows

MRTG

O Multi Router Traffic Grapher (MRTG) é uma ferramenta de monitoração que gera páginas HTML com gráficos de dados coletados a partir de SNMP ou scripts externos. É conhecido principalmente pelo seu uso na monitoração de tráfego de rede, mas pode monitorar qualquer coisa desde que o host forneça os dados via SNMP ou script.

Foi desenvolvido por Tobias Oetiker e Dave Rand. Foi escrito em Perl mas utiliza um módulo em C para gerar os gráficos.

Características

• Mede sempre 2 valores, no caso de tráfego, pode ser Entrada e Saída.
• Faz as leituras via SNMP ou através de script que retorne um formato padrão.
• Coleta dados a cada 5 minutos por padrão, mas este tempo pode ser aumentado ou diminuido.
• Cria uma página HTML com 4 gráficos (diário, semanal, mensal e anual). Se algum deles não for necessário pode ser suprimido.
• O MRTG pode avisar caso o valor do gráfico atinja um valor pré-estabelecido. Por exemplo: se determinado servidor atinge 95% do espaço do disco, o MRTG pode mandar um e-mail para o administrador informando o ocorrido.
• Possui uma ferramenta para gerar os arquivos de configuração: o CFGMAKER.
• Possui uma ferramenta para gerar um página de índice para os casos em que muitos ítens são monitorados: o INDEXMAKER.

O MRTG é software livre distribuído nos termos da GNU General Public License.

Instalando e configurando SNMP e MRTG

Neste artigo veremos como instalar e usar o SNMP e MRTG.
Os agentes SNMP devem ser executados no modo SOMENTE-LEITURA (RO) porque o coletor SNMP somente precisa ler os dados nas máquinas remotas. Limitando como tem a permissão de acessar os agentes nos dispositivos remotos aumentando um pouco a segurança.
Nunca esqueça que a comunidade SNMP está cruzando a rede em texto limpo e pode ser facilmente interceptada usando ferramentas como o WireShark, antigo Ethereal.

Serão necessários os pacotes SNMP, MRTG e o Apache rodando. Baixe os fontes de acordo com sua distribuição e instale. Instale e configure o SNMP e o MRTG nesta ordem. Tem que ser feito desta forma, pois é preciso que o SNMP esteja devidamente configurado para que o MRTG possa atuar sem problemas.

Em máquinas debian/Ubuntu Linux:

Instale o serviço SNMP:

#apt-get install snmpd

Instale o apache:
#apt-get install apache2

Depois de instalados, iremos configurar o SNMP. Edite o arquivo snmpd.conf:

# vi /etc/snmp/snmpd.conf

Existem diversos tipos de configuração para monitoramento via MRTG, neste texto trataremos de uma configuração simples e funcional.

Ache o tópico "## sec.name source community" e descomente as linhas:

com2sec     local     localhost        private
com2sec     mynet     192.168.0.0/24   public
com2sec     public    default          public

Observe a segunda linha, onde está definido o nome e o endereço da rede.

Em seguida descomente e defina as seguinte linhas:

group mygroup   v1          mynet
group mygroup   v2c         mynet
group local     v1          local
group local     v2c         local
group public    v1          public
group public    v2c         public

view all    included  .1         80
access mygroup  ""  any    noauth    0    all    none   none
access public   ""  any    noauth    0    all    none   none
access local    ""  any    noauth    0    all    all    all

Essas linhas vêm descomentadas por padrão. Deixe-as:

syslocation Unknown (edit /etc/snmp/snmpd.conf)
syscontact Root  (configure /etc/snmp/snmp.local.conf)

Pronto salve o arquivo e inicie o serviço:

# service snmpd start

Configurando MRTG

Você pode usar o comando apt-get install mrtg e o programa irá baixar e instalar automaticamente. Agora se você quiser baixá-lo, visite a página oficial do MRTG:

• MRTG – http://oss.oetiker.ch/mrtg/

O MRTG requer o seguinte para compilar e funcionar no seu Linux: gcc, perl, gd, libpng, zlib. Provavelmente sua distribuição já veio com esses pacotes, então não os cobrirei neste tutorial. Vamos agora começar a instalação:

# tar zpfx mrtg-2.9.25.tar.gz
# cd mrtg-2.9.25
# ./configure --prefix=/usr --sysconfdir=/etc/mrtg

[...configurando a compilação...]

# make

[...compilando...]

# make install

E pronto. Se tudo ocorrer bem, o MRTG estará instalado corretamente no seu sistema, e pronto para o uso! Mas antes, teremos que criar um arquivo de configuração para o MRTG usar. Para isso utilizaremos um utilitário do MRTG chamado “cfgmaker”. Tenha em mãos o IP do seu roteador e a senha “community” dele… Se você não souber o que diabos é isso, então está precisando mexer um pouco mais com o roteador :) Execute o comando:

cfgmaker --global 'WorkDir: /var/www/html/mrtg' \
--global 'Options[_]: bits,growright' \
--output /etc/mrtg/exemplo.cfg \
community@xxx.xxx.xxx.xxx

Onde “xxx.xxx.xxx.xxx” é o IP do seu roteador. Este comando irá gerar o arquivo “/etc/mrtg/exemplo.cfg” e servirá para alterarmos manualmente, comparando com o resultado. Veja este exemplo de configuração final comentada:

# ---------------------
# Configurações Globais
# ---------------------

# Diretório onde vai ficar a página com os gráficos gerados
# pelo MRTG
WorkDir: /var/www/html/mrtg

# Língua usada pelo MRTG para as mensagens na página
Language: brazilian

# Opções:
# bits = Mostrar a velocidade em bits (bits/bytes)
# growright = O gráfico cresce para a direita
Options[_]: bits,growright

# Rodar como Daemon? Assim não será preciso colocar
# no crontab, só precisará colocar um comando na
# inicialização do Linux.
RunAsDaemon: yes

# --------------------------------
# Configuração do link 1 (256kbps)
# --------------------------------

# Aqui você terá de comparar com o exemplo gerado
# pelo comando 'cfgmaker', coloque o valor igual
# ao que foi mostrado. O primeiro número é essencial
# para saber a ligação que estamos usando no roteador.
Target[EXEMPLO]: 1:community@xxx.xxx.xxx.xxx:

# A quantidade de bytes que o link suporta.
# 64kbps = 8000
# 256kbps = 32000
MaxBytes[EXEMPLO]: 32000
AbsMax[EXEMPLO]: 32000

# Com essa opção, todos os 4 gráficos não serão
# redimensionados de acordo com o uso do link. Eles sempre
# terão a altura do máximo de tráfego que se pode chegar
# (de acordo com os itens acima).
Unscaled[EXEMPLO]: dwmy

# Configurações da página. Título e frase no Topo.
Title[EXEMPLO]: Exemplo de Análise de Tráfego para link de 256kbps
PageTop[EXEMPLO]: Exemplo de Análise de Tráfego para link de 256kbps

Pronto. Já temos uma configuração básica para o MRTG. Agora vamos rodá-lo:

# mrtg

Conheça o VoIP

Muito vem sendo falado sobre a tecnologia de voz sobre IP. VoIP vem do termo em inglês Voice Over Internet Protocol ou, traduzindo, Voz Sobre o Protocolo da Internet. Esta tecnologia unifica dois mundos, tecnologia e dados em uma só rede convergente

Empresas em todo o mundo estão conseguindo economizar muito nas tarifas de ligações interurbanas e internacionais. Tudo graças a uma tecnologia chamada VoIP (Voz sobre IP), que começa a se tornar acessível também no Brasil. E não vai demorar muito para que essas quatro letras causem uma verdadeira revolução no modo de se pensar telefonia. Muitos já ousam afirmar até que o VoIP é a reinvenção da telefonia, tanto na forma de prestar o serviço, quanto de utilizá-lo.


A plataforma VoIP transforma os sinais de voz (analógicos) em pacotes digitais para transmissão tanto na Internet quanto na Intranet. Estes pacotes são compactados para transmissão a um segundo portal, no qual eles serão novamente compactados, dessa vez em sinais de som analógicos, e enviados ao receptor.


Abaixo, acompanhe um passo-a-passo de como se estabelece uma ligação telefônica pela tecnologia VoIP:

1. O usuário, com um headset, ouve a sinalização que indica telefone fora do gancho para a parte da aplicação sinalizadora da VoIP no roteador. Esta emite um sinal de discagem e aguarda que o usuário tecle um número de telefone. Esses dígitos são acumulados e armazenados pela aplicação da sessão.

2. O gateway compara estes dígitos acumulados com os números programados. Quando há uma coincidência, ele mapeia o número discado com o endereço IP do gateway de destino.

3. Em seguida, a aplicação de sessão roda o protocolo de sessão H.245 sobre TCP, a fim de estabelecer um canal de transmissão e recepção para cada direção através da rede IP. Quando a ligação é atendida, é estabelecido, então, um fluxo RTP (Real-Time Transport Protocol, ou Protocolo de Transmissão em Tempo Real) sobre UDP (User Datagram Protocol, algo como Protocolo de Pacote de Dados do Usuário) entre o gateway de origem e o de destino.

4. Os esquemas de compressão do codificador-decodificador (CODECs) são habilitados nas extremidades da conexão. A chamada, já em voz, prossegue utilizando o RTP/UDP/IP como pilha de protocolos.

Nada impede que outras transmissões de dados ocorram simultaneamente à chamada.

Sinais de andamento de chamada e outros indicativos que podem ser transportados dentro da banda cruzam o caminho da voz assim que um fluxo RTP for estabelecido.

Após a ligação ser completada, é possível também enviar sinalizações dentro da banda como, por exemplo, sinais DTMF (freqüências de tons) para ativação de equipamentos como Unidade de Resposta Audível (URA).

Quando qualquer das extremidades da chamada desligar, a sessão é encerrada, como em qualquer chamada de voz (ligação telefônica) convencional.


O é necessário para usar a comunicação VoIP, integrando Internet e telefonia?

Nessa comunicação de voz, é necessário que o usuário tenha instalado em seu computador um software para transferência de dados, no caso a voz. Vale lembrar que, para usufruir desse serviço, seu micro deve possuir um kit multimídia.

Em seu primeiro estágio, a VoIP podia ser entendida como uma conversação telefônica entre dois usuários de uma rede privada usando conversão de voz para dados (exclusivamente em redes corporativas).

Mais tarde esta tecnologia chegou ao seguinte conceito: uma conversação telefônica entre um usuário de Internet e um usuário da telefonia convencional, sem necessidade de acesso simultâneo.

VNC – Acesso remoto

O VNC (Virtual Network Computing) é um programa da Olivetti, (a AT&T absorveu), gratuito, que permite que você tenha acesso a um outro computador bastando apenas instalar o servidor em uma determinada máquina e saber o seu IP. Apos a sua instalação você tem várias opções, você pode fazer o download CLICANDO AQUI.
Aqui vamos dá ênfase ao WinVNC (app Mode) que é o programa (servidor) que você deverá executar na máquina que deseja controlar remotamente. Rode o programa (vai aparecer um ícone no canto esquerdo) e configure:


Configurações iniciais:

1. Defina logo a senha que você vai utilizar para acessar a máquina a distância;
2. Defina quantos computadores você pretende acessar ao mesmo tempo;
3. Defina também se o mouse e o teclado estarão desativados quando acessar;

É interessante para gerenciar um laboratório para aulas ou a distância.

Como usar:

1. Agora, pelo próprio navegador, digite o IP da máquina seguindo da porta 5800:

Ex.: 192.22.11.13: 5800 (supondo que o ip seja 192.33.22.13)

ou se estiver na internet
http://200.192.11.21 :5800 (supondo que o ip seja 200.192.11.21)

Você tem os dois exemplos de acesso, o primeiro em uma rede local e o segundo por internet.

2. Vamos a senha que você definiu na tela ao lado… e pronto.

Você pode usar o programa servidor VNCviewer, de ícone vermelho. Clica nele, coloca o IP e pronto.

Importante:

- O seu firewall, esperamos que esteja usando um, pode bloquear o VNC. Não esqueça de configura-lo.

- Qualquer usuário com um pouco de experiência sabe que a porta 5800 (para interface própia) e a 5900 (para aplicação WEB com aplicação java) são do VNC. Se ele scannear a sua máquina tentará invadir por essas portas!
Configure bem o seu firewall.

IP's de DNS alternativos

Os DNS alternativos são para casos onde os servidores da provedora de conexão estão inoperantes ou com problemas, lembrando que, provedor de autênticação é outra função(Terra, UOL, IG, ...).Claro que se existe um problema no caminho fisico da transmissão, não adianta trocar o DNS. Mas sempre vale essa troca para se ter certeza.

Esses problemas de conexão das operadoras podem ser resolvidos, muitas vezes, apenas trocando o DNS que se usa em sua conexão. Por padrão o Provedor de Conexão tem um DNS, mas você pode usar outro sem problemas.

Existem duas alternativas mais conhecidas e estaveis:

- Open DNS
Site: https://www.opendns.com/start/
IPs: 208.67.222.222 e 208.67.220.220

- DNS Advantage
Site: DNS Advantage
IPs: 156.154.70.1 e 156.154.71.1

Caneta detecta sinal wireless em raio de 10 metros

Uma empresa norte-americana criou a Auto Detective Pen, uma caneta que detecta qualquer sinal wireless em um raio de 10 metros. A novidade deve atrair, entre outros clientes, empresários que temem a espionagem industrial. Assim que a tal caneta percebe o sinal, um conjunto nada discreto de luzes pisca freneticamente. A caneta que detecta os anteninhas inclui ainda um sistema de iluminação que identifica notas de dinheiro falsas (ao que tudo indica, apenas dólares). Ou seja, trata-se do equipamento perfeito para quem tem mania de perseguição e os paranóicos de plantão. O conjunto de recursos funciona com baterias e sai por US$ 18 (R$ 40).

Qual placa de rede comprar

Muitas pessoas não sabem que placa de rede devem comprar para seus computadores, aqui temos algumas dicas:

1) Verifique qual o slot disponível em seu computador, e compre uma adequada.

Os slots antigos são maiores, pretos, barramento ISA.

Os slots PCI são brancos, menores, com maior densidade. Use esse, se puder.

Para efeito de acesso residencial à internet, as duas são equivalentes.

2) Compre uma de 10/100 Mbps e instale no seu micro. Não precisam ser sofisticadas, tipo 3COM, Intel, etc...

3) As comuns, das marcas Jtec, Genius, Encore, Surecom etc. custam aproximadamente R$ 30,00, e funcionam muito bem com Internet.
Atualmente as placas de R$ 30,00 dão muito bem "conta do recado", a diferença entre as placas baratas e caras é muito pequena. Fica a teu critério pagar R$ 150,00 numa 3Com só para efeito de “grife”.

TCL shell - CISCO IOS - programando um roteador

Gostaria de apresentar, para quem ainda não conhece, uma das ferramentas mais versáteis disponível para o engenheiro de rede no IOS CISCO: O TCL (Tool Command Language) shell.

Essa shell foi criada para permitir a execução de scripts TCL diretamente no IOS CISCO.

Estes scripts, claro, usam e interagem diretamente com os comandos disponíveis no IOS.

Existe também a possibilidade de criar o script e depois pré-compilar os mesmos, salvando-os na memória FLASH ou disco. Além disto, podem ser compartilhados por múltiplos usuários no mesmo roteador e ao mesmo tempo.

Um exemplo do uso dessa shell aparece na prova prática da CCIE RS onde, usualmente, pede-se conectividade total entre os equipamentos , isto é, cada IP da rede deve ser capaz de pingar qualquer outro IP.

Agora imaginem, testar conectividade de 10 equipamentos repletos de interfaces e IPs?
Pingar cada IP de cada equipamento, de dentro de cada equipamento?
E ainda verificar o que falhou e ir atrás do problema?

Tarefa complicada que o seguinte TCL script simplifica e muito. Basicamente, ele serve para filtrar a resposta do comando PING, e apenas imprimir na tela os IPs que não responderem com um ICMP echo-reply.

foreach -> cria uma loop de iteraçao com os IPs listados
[exec ping $ips timeout 3 ] -> pinga cada IP da lista e usa um timeout de 3 seg
string first "!!!" -> verifica se na string de saída do comando "ping IP" encontramos "!!!"
$result == -1 } { puts ".. $ips "}} verifica se o resultado for negativo (sem resposta do ping) imprimi na tela dois pontos (..) e o IP que não respondeu.

r1#tclsh
r1(tcl)#proc pingall {} {
+>(tcl)#foreach ips {
+>(tcl)#155.1.1.1
+>(tcl)#155.4.4.4
+>(tcl)#155.6.6.6}
+>(tcl)#{ set result [ string first "!!!" [exec ping $ips timeout 3 ] ]
+>(tcl)#if { $result == -1 } { puts ".. $ips " } }
+>(tcl)#}
r1(tcl)#pingall
.. 155.4.4.4
.. 155.6.6.6

Somente para relembrar a saída tipica de um ping e entender melhor o exemplo:

r1#ping 155.1.1.1 timeout 3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.1.1, timeout is 3 seconds:
!!!!!
Success rate is 100 percent (5/5)

Assim como o script verificou os "!!!" na saída do comando, nada foi impresso na tela

E para um ping que não recebeu resposta:

r1#ping 155.4.4.4 timeout 3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.4.4.4, timeout is 3 seconds:
.U.U.
Success rate is 0 percent (0/5)

O script não encontra "!!!" e imprime na tela ".. e o IP"

TCL SCRIPT:

tclsh
proc pingall {} {
foreach ips {
172.16.16.1
172.16.123.1
172.16.14.1
172.16.50.25} { set result [ string first "!!!" [ exec ping $ips ] ]
if { $result == -1 } { puts ".. $ips " } }
}

Protocolo OSPF

O OSPF é um protocolo de roteamento feito para redes com protocolo IP; foi desenvolvido pelo grupo de trabalho de IGPs (Interior Gateway Protocol) da IETF (Internet Engineering Task Force). Este grupo de trabalho foi criado em 1988, para projetar um IGP baseado no algoritmo Shortest Path First (SPF, menor rota primeiro), voltado para uso na Internet. Similar ao Interior Gateway Routing Protocol (IGRP), protocolo proprietário da Cisco, o OSPF foi criado, pois, na metade dos anos 80, o Routing Information Protocol (RIP) mostrou-se cada vez menos capaz de atender redes largas e heterogêneas.

O OSPF resultou de diversas pesquisas: a de Bolt, Berenek e Newman (BBN), que desenvolveram o algoritmo SPF em 1978, para a ARPANET (o marco inicial das redes de comutação de pacotes, criada no início dos aos 70 por BBN); a de Radia Perlman, a respeito da tolerância a erros de transmissão no roteamento de informação (de 1988); e a de BBN sobre roteamento local (1986), uma versão inicial do protocolo de roteamento OSI entre camadas intermediárias.

Há duas características principais no OSPF. A primeira, é um protocolo aberto, o que significa que suas especificações são de domínio público; suas especificações podem ser encontradas na RFC (Request For Comments) número 1247. A segunda, é um protocolo baseado no algoritmo SPF, também chamado de algoritmo de Dijkstra, nome de seu criador.

OSPF é um protocolo de roteamento do tipo link-state, que envia avisos sobre o estado da conexão (link-state advertisements, LSA) a todos os outros roteadores em uma mesma área hierárquica. Informações sobre interfaces ligadas, métrica usada e outras variáveis são incluídas nas LSAs. Ao mesmo tempo em que o roteador OSPF acumula informações sobre o estado do link, ele usa o algoritmo SPF para calcular a menor rota para cada nó.

Diferenças RIP - BGP - OSPF

Aqui está um pequeno resumo que mostra de forma não aprofundada algumas das principais diferenças entre os protocolos de roteamento RIP (Routing Information Protocol), OSPF (Open Shortest Path First) e BGP (Border Gateway Protocol):

RIP - Só conhece o próximo passo na rede, limita saltos entre hosts à 15.

OSPF - Cada roteador só conhece sua própria AS*. Os roteadores de borda conhecem a sua própria rede mais o broadcast.

BGP - Reconhce até 6 níveis de profundidade, e prevê os próximos passos dele e dos seus vizinhos.


*AS é a sigla de autonomous system, também conhecido como um domínio de roteamento.  É um conjunto de roteadores sob a mesma administração. Por exemplo a rede interna de uma empresa e a rede de um provedor de Internet.

Tabelas de Vizinhos

Ao descobrir um novo vizinho, o roteador registra os respectivos endereço e interface como uma entrada na tabela de viznhos. Quando um vizinho envia um pacote hello, ele anuncia um tempo de ocupação, correspondente à quantidade de tempo que um roteador considerará que um vizinho está operacional e pode ser alcançado. Se um pacote helllo não for recebido durante esse tempo de ocupação, o tempo expirará e a máquina DUAL, será informada sobre a mudança de topologia.
A entrada da tabela de vizinhos também inclui as informações exigidas pelo protocolo RTP. Números consecutivos são empregados para oncincidir os reconhecimentos co os pacotes de dados e o último número sequencial recebido do vizinho é registrado, o que permitirá a identificação de pacotes fora de ordem. Uma lista de transmissão é utilizada para a cruação de uma fila de pacotes uma possível transmissão par cada vizinho. Registros de tempos de ida-e-volta são mantidos na entrada da tabela de vizinhos para calcular uma estimativa do melhor intervalo de transmissão.

Extraído das páginas 384 e 385 do livro Internet Working Technologies Handbook - Tradução da Segunda Edição.

RIP (Routing Information Protocol)

O RIP foi desenvolvido pela Xerox Corporation no início dos anos 80 para ser utilizado nas redes Xerox Network Systems (XNS), e, hoje em dia, é o protocolo intradominio mais comum, sendo suportado por praticamente todos os fabricantes de roteadores e disponível na grande maioria das versões mais atuais do sistema operacional UNIX.

Um de seus beneficios é a facilidade de configuração. Além disso, seu algoritmo não necessita grande poder de computação e capacidade de memória em roteadores ou computadores.

O protocolo RIP funciona bem em pequenos ambientes, entretanto apresenta sérias limitações quando utilizado em redes grandes. Ele limita o numero de saltos (hops) entre hosts a 15 (16 é considerado infinito). Outra deficiência do RIP é a lenta convergência, ou seja, leva relativamente muito tempo para que alterações na rede fiquem sendo conhecidas por todos os roteadores. Esta lentidão pode causar loops de roteamento (por exemplo um mesmo pacote fica passando entre os roteadores A, B e C até acabar o TTL), por causa da falta de sincronia nas informacões dos roteadores.

O protocolo RIP é também um grande consumidor de largura de banda, pois, a cada 30 segundos, ele faz um broadcast de sua tabela de roteamento, com informações sobre as redes e sub-redes que alcanca.

Por fim, o RIP determina o melhor caminho entre dois pontos, levando em conta somente o numero de saltos (hops) entre eles. Esta técnica ignora outros fatores que fazem diferença nas linhas entre os dois pontos, como: velocidade, utilização das mesmas (tráfego) e toda as outras métricas que podem fazer diferenca na hora de se determinar o melhor caminho entre dois pontos.

Tabela de Roteamento

Quando um pacote chega em uma das interfaces do roteador, ele analisa a sua tabela de roteamento, para verificar se na tabela de roteamento, existe uma rota para a rede de destino. Pode ser uma rota direta ou então para qual roteador o pacote deve ser enviado. Este processo continua até que o pacote seja entregue na rede de destino, ou até que o limite de 16 hopes (para simplificar imagine um hope como sendo um roteador da rede) tenha sido atingido.

Na Figura a seguir apresento um exemplo de uma "mini-tabela" de roteamento:

Cada linha é uma entrada da tabela. Por exemplo, a linha a seguir é que define o Default Gateway da ser utilizado:

0.0.0.0 0.0.0.0 200.175.106.54 200.175.106.54 1

Na imagem abaixo vemos uma tabela de roteamento onde mostra por quais gateways é necessário passar para ir de uma Lan a outra:
podemos ver que por exemplo para ir da Lan1(10.0.0.0) até a Lan3 (30.0.0.0) é preciso passar pelo roteamento do Gateway 1 e Gateway 2.

Segurança do Bluetooth

O Bluetooth tem três modos de segurança, variando desde nenhuma segurança até total criptografia de dados e controle de integridade. Se a segurança for destivada, não haverá nenhuma segurança. Grande parte dos usuários mantéma segurança desativada até ocorrer uma séria violação, depois eles a ativam. No mundo agrícola, essa abordagem é conhecida como trancar a porteira depois que o cavalo escapou.

O Bluetooth fornece segurança em várias camadas. Na camada física, os saltos de frequência oferecem um nível mínimo de segurança mas, como qualquer dispositivo Bluetooth que se desloca em uma piconet tem de ser informado da sequência de saltos de frequencia, é óbvio que essa frequência não é um segredo. A segurança real começa quando o escravo recém-chegado solicita um canal ao mestre. Supõe-se que os dois dispositivos compartilham uma chave secreta configurada com antecedência.

Para estabelecer um canal, o escravo e o mestre verificam se a outra máquina conhece a chave de passagem. Nesse caso, eles negociam para ver se esse canal será criptografado, terá sua integridade controlada ou ambos. Em seguida, eles selecionam uma chave de sessão aleatória de 128 bits, na qual alguns bits podem ser públicos. A razão para permitir o enfraquecimento dessa chave é obedecer a algumas restrições do governo de vários países, criadas para impedir a exportação ou o uso de chaves mais longas do que o governo pode violar.

O Bluetooth efetua a autenticação apenas de dispositivos, não de usuários. Desse modo, quando um ladrão rouba um dispositivo Bluetooth ele pode ter acesso às finanças e às contas do usuário. No entento, o Bluetooth também implementa segurança nas camadas superiores do que a do enlace. Assim mesmo se houver violação da segurança no nível de enlace, deve restar alguma segurança, especialmente para aplicações que exigem a digitação de um código PIN em algum tipo de teclado para completar a transação.

Protocolo de gateway de borda (BGP)

O roteamento envolve duas atividades básicas: a determinação dos melhores caminhos de roteamento e o transporte de grupos de informação (tipicamente chamados de pacotes) em uma internetwork. O transporte de pacotes pela internetwork é relativamente direto. Por outro lado, a determinação do caminho pode se tornar muito complexa. Um protocolo destinado à tarefa de determinação do caminho nas redes atuais é o Protocolo de Gateway de Borda (BGP).
O Protocolo BGP executa o roteamento entre domínios em redes TCP/IP. O BGP é um protocolo de gateway externo (EGP), siginificando que executa o roteamento entre vários domínios ou sistemas autônomos e faz o intercâmbio com outros sistemas de BGP de informações sobre roteamento e sobre a capacidade de determinados destinos.
O protocolo BGP foi desenvolvido para substituir seu antecessor, o agora obsoleto Protocolo de Gateway externo (EGP), como padrão de protocolo de roteamento de gateway externo utilizado na Internet global. O BGP soluciona, de maneira mais eficaz, sérios problemas com o EGP e asescalas para um crescimento mais eficiente na Internet.

Extraído da página 373 do livro INTERNET WORKING MANUAL DE TECNOLOGIAS - Tradução da Segunda Edição

AWStats

AWStats é uma ferramenta open source de relatórios de análise site, apta para analisar dados de serviços de Internet( como um servidor site, streaming, mail e FTP). AWstats analisa os arquivos de log do servidor, e com base a eles produz relatórios HTML. Os dados são apresentados visualmente em relatórios de tabelas e gráficos de barra. Podem criar-se relatórios estáticos mediante uma interface de linha de comando, e podem-se obter relatórios on-demand através de um navegador site, graças a um programa CGI.

AWStats suporta a maioria dos formatos de arquivos log de servidor site conhecidos, entre eles Apache (formato de log NCSA combinado/XLF/ELF ou formato comum/CLFt), WebStar, IIS (formato de log do W3C) e muitos outros formatos comuns de Internet. Os programadores podem contribuir com o projecto AWStats através de SourceForge.

Escrito em Perl, AWStats pode ser utilizado na maioria dos sistemas operacionais. É uma aplicação muito popular como ferramenta de administração de servidores, com pacotes disponíveis para a maioria das distribuições Linux, o AWStats também pode ser utilizado em Sistemas operacionais Windows e Mac OS.

Para instalar no Linux (distribuições como o Ubuntu) basta colocar o seguinte comando no terminal: apt-get install awstats

Segurança de Rede - Linux

Introdução
A cada dia novos usuários de Linux surgem todos os dias, e graças à facilidade de acesso à Internet nos dias atuais a maior parte deles conecta suas máquinas pessoais a redes abertas sem maiores dificuldades.

Sabendo que o Linux é um sistema capaz de ser administrado remotamente, e que muitas configurações default de distribuições habilitam muitos processos servidores para iniciar automaticamente após a instalação, estes novos usuários acabam se transformando em uma ameaça a si próprios, pois expõem à Internet uma máquina aberta, devido à sua falta de conhecimento técnico.

Para piorar a situação, há abundância de textos sobre "segurança" disponíveis na internet, "ensinando" que para garantir uma configuração segura da sua máquina, tudo o que você tem a fazer é "comentar as linhas do inetd.conf", um conselho enganoso.

Primeiros passos

A segurança começa pela instalação do seu sistema Linux. Se você tem uma máquina sem configurações especiais de segurança e quer torná-la segura, uma opção interessante é reinstalá-la completamente, suprimindo assim qualquer erro que tenha sido cometido no passado; lembre-se que uma máquina invadida e onde estranhos obtiveram privilégios de superusuário jamais poderá ser considerada segura novamente, exceto se totalmente reinstalada a partir de uma mídia original (e se você corrigir as falhas que permitiram a invasão original).

Ao instalar o sistema, lembre-se dos seguintes itens:

*Só exponha o sistema à Internet após completar todos os procedimentos de segurança. Há muitos relatos de máquinas invadidas durante o processo de configuração inicial, graças a administradores que preferem confiar na sorte;
*Se a sua distribuição permitir, opte por uma instalação personalizada, e escolha apenas os pacotes que você sabe que irá usar. É muito fácil adicionar pacotes posteriormente, e será sempre um alívio quando você receber e-mail do seu fornecedor recomendando um upgrade urgente de segurança do servidor de Real Audio, e em seguida perceber que não precisa fazer nada a respeito pois não o instalou;
*Monte seu esquema de partições adequadamente. Se você for rodar algum serviço que gere armazenamento de dados em disco (uma proxy web, um servidor de mail, um servidor de news...), certifique-se de criar uma partição separada para o /var, evitando assim que os arquivos dos seus processos servidores possam lotar o espaço de armazenamento da máquina, tirando-a de operação (coisa que normalmente só pode ocorrer em caso de má configuração dos servidores, mas não há por que não levar a sério esta possibilidade);
*Após instalar todos os pacotes, instale todas as atualizações de segurança disponíveis no web site do seu fornecedor. Assine a lista de divulgação de novas atualizações, se disponível;
*Habitue-se a visitar sites de segurança para saber as novas vulnerabilidades a que você pode estar exposto.

Serviços desnecessários

Uma instalação padronizada de sistema operacional costuma habilitar uma série de serviços dos quais você não precisa, e que podem vir a servir como ponto de acesso para um invasor. Removê-los é relativamente fácil, e um passo essencial.

Editar corretamente o arquivo /etc/inetd.conf é básico. Este arquivo define quais os serviços básicos de internet estarão habilitados na sua máquina, e portanto acessíveis a partir de outras máquinas. Verifique atentamente quais destes serviços estão habilitados, e retire os que você não tiver uma boa justificativa para manter. Na dúvida, retire!

Retirar um serviço do inetd.conf é simples, basta acrescentar um caracter # no início da linha, transformando-a em um comentário. Se posteriormente você precisar habilitar novamente o serviço, basta retirar o #.

Máquinas domésticas em geral não precisam de nenhum serviço habilitado no inetd.conf, e podem até mesmo deixar de carregar o serviço inetd (inetd) na inicialização. Usuários de serviços online (como o irc) podem querer habilitar apenas o serviço auth. Não se deixe enganar pela ilusão de rodar servidores telnet, ftp e finger na sua máquina doméstica, exceto se você realmente tiver uma boa justificativa.

Após definir a sua configuração do inetd.conf, reinicie o processo do inetd, comandando killall -HUP inetd

Em seguida, você precisa verificar os serviços de rede standalone, que não são gerenciados pelo inetd.conf, mas sim pelos init scripts, de modo geral localizados abaixo do diretório /etc/rc.d. Cada distribuição de Linux lida com estes scripts de uma maneira um pouco diferente, então você terá que ler um pouco da documentação da sua preferida. Ferramentas como o ntsysv, o ksysv e o tksysv podem ajudar, e a sua distribuição pode ter oferecido algum outro pacote adicional que permita selecionar os scripts facilmente.

De modo geral, os init scripts definem quais serviços serão inicializados no momento do boot. Alguns serviços são aparentemente inócuos do ponto de vista de uma possível invasão (e.g. sound, random, apmd), enquanto outros claramente oferecem algum raio de ação para o potencial invasor (e.g. portmap, xntpd, netfs, rstatd, rusersd, rwalld, rwhod, bootparamd, squid, yppasswd, ypserv, dhcpd, snmpd, named, routed, lpd, gated, httpd, xfs, linuxconf e muitos outros).

Ao definir quais scripts você executará no boot, use o mesmo critério da seleção dos serviços do inetd; na dúvida, retire - se mais tarde você precisar, adicione novamente (após avaliar o impacto sobre a segurança). Particularmente evite rodar o servidor do linuxconf, rstatd, rusersd, rwalld, rwhod, os serviços do NIS (yp*) e os daemons de roteamento (como o gated). Se você for rodar um servidor web para uso interno, ou para testes, certifique-se de configurá-lo para aceitar requests apenas da sua rede interna, ou de sua máquina pessoal - segurança de servidores não será coberta neste texto.

Cuidado ao mexer nos scripts de inicialização

Leia sempre a documentação antes, e tenha à mão um disquete de inicialização completa, como o tomsrtbt para emergências, já que provavelmente o disquete de boot gerado durante a sua instalação do Linux não resolverá o problema. Outra boa dica é aprender a iniciar o sistema em modo monousuário quando tudo falhar.

Detalhes

*Desenvolva uma estratégia de backups confiável;
*Instale ferramentas de análise e rotação de logs;
*Instale ferramentas de garantia de integridade, como o tripwire (principalmente nos servidores);
*Certifique-se de estar usando shadow passwords (nada de senhas criptografadas visíveis no /etc/passwd - este recurso já vem habilitado como default em algumas das distribuições);
*Se você estiver com o servidor de ftp habilitado, configure-o adequadamente; não permita o acesso de root, restrinja a árvore de diretórios, reveja os direitos de acesso anônimos, considere a possibilidade de as senhas de acesso estarem sendo monitoradas em sua rede local;
*Desabilite o telnet e o ftp. Se você precisar deste tipo de serviço, use o ssh (tanto para login quanto para transferência de arquivos);
*Habilite os tcp wrappers (tcpd) e configure adequadamente os arquivos de restrição e permissão de acesso (em geral, /etc/hosts.deny e /etc/hosts.allow);
*Habilite filtros de pacotes (usando ipfwadm, ipchains ou a ferramenta que estiver disponível na sua versão);
*Não permita que outras máquinas iniciem conexões com a sua, exceto para as portas que você explicitamente definir;
*Bloqueie o acesso às portas dos seus serviços locais (xfs, X, servidor web utilizado para testes...).

Monitoração remota (RMON)

A monitoração emota (RMON) é uma especificação padrão de monitoração, que habilita vários sistemas e console e monitores de rede para o intercâmbio de dados de monitoração de rede. A RMON proporciona aos administradores de rede maior liberdade para seleção de consoles e sondas de monitoração com características que satisfaçam às necessidades específicas de suas redes.

A especificação RMON define um conjunto de estatísticas e funções que podem ser permutadas entre sondas de rede e gerentes de console compatíveis com a RMON. Dessa maneira a RMON, proporciona aos administradores uma diagnose abrangente de falhas na rede, planejamento e informações para o ajuste de desempenho.

Grupos RMON

A RMON fornece informações em nove grupos RMON de elementos de monitoração, cada um oferecendo conjuntos específicos de dados para atender às necessidades de monitoração de rede. Cada grupo é opcional, permitindo que cada fabricante ão precise incluir na MIB (Base de informaçõe de administração) todos os grupos.

Alguns grupos de RMON precisam de suporte de outros grupos RMON para que possam funcionar de maneira correta.

Extraído das páginas 525 e 526 do livro INTERNET WORKING MANUAL DE TECNOLOGIAS - Tradução da Segunda Edição.

IPTables

Iptables é um Firewall.
Um firewall é uma barreira inteligente entre duas redes, através do qual só passa tráfego autorizado.
Este tráfego é examinado pelo firewall em tempo real e a seleção é feita de acordo com a política de segurança estabelecida.
O IPTables composto por 3 tabelas:
¹filter: Tabela de filtros de pacotes;
²NAT (network address translation): Conexão de várias máquinas com endereço falso á internet através de poucos endereços IP ́s válidos;
³mangle: Altera o conteúdo dos pacotes.

O que são regras:

As regras são como comandos passados ao iptables para que ele realize uma determinada ação (como bloquear ou deixar passar um pacote) de acordo com o endereço/porta de origem/destino, interface de origem/destino, etc. As regras são armazenadas dentro dos chains e processadas na ordem que são inseridas.

As regras são armazenadas no kernel, o que significa que quando o computador for reiniciado tudo o que fez será perdido. Por este motivo elas deverão ser gravadas em um arquivo para serem carregadas a cada inicialização.

Um exemplo de regra: iptables -A INPUT -s 123.123.123.1 -j DROP.

O que são chains:

Os Chains são locais onde as regras do firewall definidas pelo usuário são armazenadas para operação do firewall. Existem dois tipos de chains: os embutidos (como os chains INPUT, OUTPUT e FORWARD) e os criados pelo usuário. Os nomes dos chains embutidos devem ser especificados sempre em maiúsculas (note que os nomes dos chains são case-sensitive, ou seja, o chain input é completamente diferente de INPUT).

Quando um pacote chega a uma table é verificado se alguma regra se aplica a ele. Caso não haja, é aplicada a política defaut.
Constituído por 3 chains:

INPUT – Pacote destinado a maquina de firewall.
OUTPUT – Pacote originado da maquina de firewall.
FORWARD – Pacote com destino e origem
separados pela maquina de firewall.

Quando um pacote entra numa interface de rede:
Se o pacote é para a máquina é enviado para o chain INPUT;
Se o destino não é esta máquina e o serviço de routing está ativo, o pacote vai para o chain FORWARD;
Se um processo da máquina envia um pacote para a rede o pacote vai para o chain OUTPUT.

Política Default:
A política default do firewall consiste na regra que será utilizada caso algum pacote não se encaixe em nenhuma das regras estabelecidas.
É altamente recomendado que a política default seja DROP, ou seja, tudo o que não for expressamente permitido será descartado (proibido).

Squid - proxy

O servidor Squid Web Proxy Cache é gratuito e funciona em código aberto para Unix e Linux. Ele permite que os administradores implementem um serviço de proxy caching para Web, acrescentem controles de acesso (regras) e armazenem até mesmo consultas de DNS.
Ele surgiu de um projeto entre o governo norte-americano e a a Universidade do Colorado.
Muitas das distribuições já vem com o squid instalado, mas caso sua distribuição não tenha o squid instalado visite o site www.squid-cache.org - e baixe a versão conforme a sua distribuição. Caso utilize Ubuntu, para instala-lo basta digitar no terminal: apt-get install squid

Proxy

Os proxies são principalmente usados para permitir acesso à Web através de um firewall (fig. 1). Um proxy é um servidor HTTP especial que tipicamente roda em uma máquina firewall. O proxy espera por uma requisição de dentro do firewall, a repassa para o servidor remoto do outro lado do firewall, lê a resposta e envia de volta ao cliente.

Figura 1: Visão geral de um proxy

O proxy está rodando ou em um servidor firewall ou qualquer outro servidor interno que tenha acesso total a internet - ou em uma máquina dentro do firewall fazendo conexões com o mundo exterior através de SOCKS ou qualquer outro software firewall.

Normalmente, o mesmo proxy é usado por todos os clientes em uma subrede. Isto torna possível para ele fazer caching eficiente de todos os documentos requisitados.

A habilidade que o proxy tem no uso do cache, o torna atrativo para aqueles que não estão dentro do firewall. Configurar um servidor proxy é fácil e os mais populares programas clientes Web já tem suporte a essa ferramenta. Sendo assim, torna-se simples a tarefa de configurar um grupo de trabalho inteiro para usar o serviço de cache do proxy. Isto reduz os custos com tráfego de rede porque muitos documentos que são requisitados são lidos do cache local.

A metodologia atual é baseada em um código de gateway escrito por Tim Berners-Lee como parte do libwww ( WWW commom Library). Kevin Altis, Ari Luotonen e Lou Montulli foram os principais contribuidores para a padronização do proxy.

Lou Montulli, autor de Lynx, fez as primeiras mudanças no libwww em colaboração com Kevin Altis. Ari Luotonen mantém o CERN httpd.


Porque proxy fica no nível de aplicação?

Um nível de aplicação proxy faz um firewall seguramente permeável para os usuários na organização sem criar um furo na segurança onde hackers poderiam entrar na rede da organização.
Para clientes Web, as modificações necessárias para suportar um nível de aplicação proxy são menores (leva-se apenas 5 minutos para adicionar suporte proxy para o Emacs Web Browser).
Não há necessidade de compilar versões especiais de clientes Web com bibliotecas firewall, o cliente "out-of-the-box" pode ser configurado para ser um cliente proxy. Em outras palavras, quando se usa proxy não necessitamos customizar cada cliente para suportar um tipo ou método especial de firewall: o proxy, em si, é um método padrão para acessar firewalls.

Usuários não têm que ter clientes FTP, Gopher e WAIS separados (muito menos modificados) para acessar um firewall - um simples cliente Web com um servidor proxy trata todos esse casos. O proxy também padroniza a aparência de clientes Gopher e FTP.
O proxy permite que os programadores esqueçam as dezenas de milhares de linhas de código necessárias para suportar cada protocolo e se concentrem em coisas mais importantes - é possível ter clientes "peso-leve" que somente compreendam HTTP (nenhum suporte nativo aos protocolos FTP, Gopher, etc) - outros protocolos são manuseados transparentemente pelo proxy. Usando HTTP entre o cliente e o proxy, nenhuma funcionalidade


Clientes sem DNS (Domain Name Service) também podem usar a Web. O endereço IP do proxy é a única informação realmente necessária. Organizações usando endereços, por exemplo, classe A (como 10.*.*.*), em suas redes particulares podem ainda acessar a internet contanto que o proxy seja visível tanto para a rede particular como para a Internet.
Proxy permite um alto nível de log das transações de clientes, incluindo endereço IP, data e hora, URL, contagem de bytes e código de sucesso. Qualquer campo (seja de meta-informação ou seja comum) em uma transação HTTP é um candidato para log. Isto não é possível com log no nível IP ou TCP.

Também é possível fazer a filtragem de transações de clientes no nível do protocolo de aplicação. O proxy pode controlar o acesso a serviços por métodos individuais, servidores e domínios, etc.
Outra feature interessante do proxy é a cache. O uso de cache é mais efetivo no servidor proxy do que em cada cliente. Isto salva espaço em disco, desde que somente uma cópia é guardada, como também permite um uso de "cache inteligente", onde os documentos frequentemente referenciados por muitos clientes são guardados por um periodo mais longo de tempo pelo cache manager.
O uso de cache também torna possível acessar algumas páginas mesmo que servidores estejam fora do ar. Essa facilidade torna o serviço melhor, visto que recursos remotos como um site FTP ocupado que são frequentemente inacessíveis remotamente podem ser agora acessíveis através do cache local. Pode-se citar uma infinidade de usos que podemos fazer com o cache: fazer uma demonstração de algum lugar com uma baixa velocidade de conexão, ler documentos com a máquina não-conectada (obviamente após colocar todos documentos no cache local), etc.

Clientes sem DNS (Domain Name Service) também podem usar a Web. O endereço IP do proxy é a única informação realmente necessária. Organizações usando endereços, por exemplo, classe A (como 10.*.*.*), em suas redes particulares podem ainda acessar a internet contanto que o proxy seja visível tanto para a rede particular como para a Internet.
Proxy permite um alto nível de log das transações de clientes, incluindo endereço IP, data e hora, URL, contagem de bytes e código de sucesso. Qualquer campo (seja de meta-informação ou seja comum) em uma transação HTTP é um candidato para log. Isto não é possível com log no nível IP ou TCP.
Também é possível fazer a filtragem de transações de clientes no nível do protocolo de aplicação.

O proxy pode controlar o acesso a serviços por métodos individuais, servidores e domínios, etc.
Outra feature interessante do proxy é a cache. O uso de cache é mais efetivo no servidor proxy do que em cada cliente. Isto salva espaço em disco, desde que somente uma cópia é guardada, como também permite um uso de "cache inteligente", onde os documentos frequentemente referenciados por muitos clientes são guardados por um periodo mais longo de tempo pelo cache manager.

O uso de cache também torna possível acessar algumas páginas mesmo que servidores estejam fora do ar. Essa facilidade torna o serviço melhor, visto que recursos remotos como um site FTP ocupado que são frequentemente inacessíveis remotamente podem ser agora acessíveis através do cache local. Pode-se citar uma infinidade de usos que podemos fazer com o cache: fazer uma demonstração de algum lugar com uma baixa velocidade de conexão, ler documentos com a máquina não-conectada (obviamente após colocar todos documentos no cache local), etc.

Em geral, autores de clientes Web não tem razão para usar versões de firewalls em seus códigos. O proxy é mais simples para configurar do que SOCKS e trabalha em todas as plataformas, não somente UNIX.

Componentes Básicos do SNMP

Uma rede administrada com o SNMP é composta por três componentes principais: dispositivos gerenciados, agentes e sistemas de administração de redes(NMSs).

Um dispositivo administrado é um nó de rede que contém um agente SNMP e que se encontra em uma rede adiministrada. Os dispositivos administrados coletam e armazenam informações de administração e tornam essas informações disponíveis para os sistemas NMSs que utilizam o protocolo SNMP. Os dispositivos gerenciados, às vezes chamados de elementos de rede, podem ser roteadores e servidores de acesso, switches e bridges, hubs, l com o protocolo SNMPcomputadores hots ou impressora.

Um agente Smith é um módulo de software de administração de rede localizado em um dispositivo administrado. O agente possui um conhecimento local das informações de administração e traduz essas informações em uma forma compatível com o protocolo SNMP.

Os sistemas NMS executam aplicações que monitoram e controlam os dispositivos administrados. Os NMSs fornecem o volume de recursos de processamento e de memória necessários para a administração de rede. É preciso haver um ou mais sistemas NMSs em qualquer rede que seja administrada.

Extraído da página 529 do Livro INTERNET WORKING TECHNOLOGIES HANDBOOK – Tradução da segunda edição.

Tunnelling

Tunnelling (tunelamento) é a capacidade de criar túneis entre duas máquinas por onde certas informações passam.

Em se tratando de um ramo do protocolo TCP/IP, o SSH e o Telnet, pode-se criar uma conexão entre dois computadores, intermediada por um servidor remoto, fornecendo a capacidade de redirecionar pacotes de dados.

Por exemplo, se alguém se encontra dentro de uma instituição cuja conexão à Internet é protegida por um firewall que bloqueia determinadas portas de conexão, não será possível, por exemplo, acessar e-mails via POP3, o qual utiliza a porta 110, nem enviá-los via SMTP, pela porta 25.

As duas portas essenciais são a 80, para HTTP e a 443, para HTTPS, as quais garantem uma navegação em páginas da Web sem restrições.

Não há necessidade do administrador da rede deixar várias portas abertas, uma vez que conexões indesejadas e que comprometam a segurança da instituição possam ser estabelecidas através mesmas.

Contudo, isso compromete a dinamicidade de aplicações na Internet. Um funcionário ou aluno que queira acessar painéis de controle de sites, arquivos via FTP ou amigos via Instant Messengers, por exemplo, não terá a capacidade de fazê-lo, uma vez que as respectivas portas para seus funcionamentos estão bloqueadas.

Para quebrar essa imposição rígida, porém necessária, o SSH oferece o recurso do Túnel.

O processo se caracteriza por duas máquinas ligadas ao mesmo servidor SSH, que faz apenas o redirecionamento das requisições do computador que está sob firewall.

O usuário envia para o servidor um pedido de acesso ao servidor pop.xxxxxxxx.com pela porta 443 (HTTPS), por exemplo. Então, o servidor acessa o computador remoto e requisita a ele o acesso ao protocolo, retornando um conjunto de pacotes referentes à aquisição.

O servidor codifica a informação e a retorna ao usuário via porta 443. Sendo assim, o usuário tem acesso a toda a informação que necessita.

É importante salientar que a prática do Tunnelling não é ilegal caso o fluxo de conteúdo esteja de acordo com as normas da instituição.

Criando um túnel SSH

# ssh -l usuário localhost -L2004:serviço a ser acessado:80 -f sleep 60

Isso basicamente redireciona o tráfego da porta 80 do servidor remoto para a porta 2004 do host local, com um timeout de 60 segundos.

Agora, no seu browser basta colocar o endereço:

http://localhost:2004

Assim sua navegação está encriptada.

Operações do SNMP

Lista de operações suportadas pelo SNMP:

*Get - Utilizada para ler o valor de uma variável; o gerente solicita que o agente obtenha o valor da variável;

*Set - Utilizada para alterar o valor da variável; o gerente solicita que o agente faça uma alteração no valor de uma variável;

*Trap - Utilizada para comunicar um evento ; o agente comunica ao gerente o acontecimento de um evento previamente determinado.

Configuração de rede em Linux

Identificação da interface de rede

O primeiro passo deste tutorial é para configurar uma rede no Linux. Identificar a placa de rede (ou mais) instaladas. Utilize o comando: sudo mii-tool
Um resultado desse comandopossível seria: eth0: negotiated 100baseTx-FD, link ok
Indicando que o sistema contém a placa (interface) denominada eth0, operando a 100 Mbps e com link operacional.

Configuração da interface de rede

Para configurar esta placa deve-se editar o arquivo /etc/network/interfaces. Um exemplo seria:
auto lo
# Configurar interface de loopback na inicialização
iface lo inet loopback# Definição da interface de loopback
auto eth0
#Configurar interface eth0 na inicialização
iface eth0 inet static
# Interface eth0 com endereço estático
address 192.168.1.1
# Endereço da interface
netmask 255.255.255.0
# Máscara de rede
broadcast 192.168.1.255
# Endereço de broadcast
gateway 192.168.1.254
# Gateway padrão
auto eth1
# Configurar interface eth1 na inicialização
iface eth1 inet dhcp
# Configurar por DHCP

Para fazer com que uma interface pare de funcionar temporariamente digite o comando:
sudo ifdown eth0

Para fazer com que uma interface entre em operação digite o comando:
sudo ifup eth0

Para verificar como está configurada uma interface digite o comando:
ifconfig eth0

Para configurar uma interface temporariamente (para definir um endereço, máscara e gateway) digite o comando:
sudo ifconfig eth0 192.0.0.1 netmask 255.255.255.0 gw 192.0.0.254 up

Gateway e roteamento

Para definir um gateway, é necessário estabelecer uma rota. Por exemplo:
sudo route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.0.0.254
irá criar uma rota para a rede 0.0.0.0 com máscara 0.0.0.0 (ou seja, a Internet) passando pelo gateway 192.0.0.254.

Nome do computador

O nome da máquina deve ser definido de duas formas. Primeiramente com o comando hostname:
sudo hostname PontodeRedesServer

E o arquivo /etc/hosts deve ter, no mínimo, linhas como as seguintes:
127.0.0.1 localhost
127.0.1.1 PontodeRedesServer

Servidores de DNS

Para definir o endereço dos servidores DNS a serem consultados, utiliza-se o arquivo /etc/resolv.conf. Um exemplo de arquivo seria:
nameserver 200.199.198.197
nameserver 197.198.199.200

Diferenças entre as versões SNMP

SNMP v1

O SNMPv1 consiste de três documentos:
RFC 1155 define o Structure of Management Information (SMI). Ou seja, os mecanismos usados para descrever e nomear os objetos que serão gerenciados
>RFC 1212 define um mecanismo de descrição mais conciso mas é inteiramente consistente ao SMI.
>RFC 1157 define o Simple Network Management Protocol (SNMP)

Os dois primeiros documentos definem a linguagem de dados. O terceiro documento define as operações do protocolo SNMPv1 utilizando protocol data units (PDUs). Os operadores definidos no SNMPv1 são: get, get-next, get-response, set-request e trap.

Muitos dos conceitos de segurança e administração encontrados no SNMPv3 são encontrados no modelo do SNMPv1.
O SNMPv1 introduz o conceito serviço de autenticação suportando um ou mais métodos. No SNMPv3 o conceito de autenticação foi expandido para incluir serviços como privacidade.

O modelo SNMPv1 possui o controle de acesso baseado num conceito chamado SNMP MIB view. O SNMPv3 especifica um conceito fundamentalmente similar chamado view-based access control.

Apesar do SNMPv1 ter antecipado um serviço de autenticação suportando vários métodos, não foi criado nenhum método além de uma simples autenticação baseada em community strings. Essa foi a grande deficiência do SNMPv1. Como o conceito de "segurança" pode ser interpretado de modo bastante diferente por cada usuário, o serviço de autenticação do SNMPv1 ficou para ser definido em um outro bloco o qual nunca foi posto em prática. O modelo SNMPv3 já possui uma arquitetura para esse bloco.

SNMPv2

O SNMPv2 está descrito nas RFCs: 1902, 1903,1904, 1905, 1906, and 1907. A relação entre o SNMPv1 e o SNMPv2 está descrita no RFC 1908.

O SNMPv2 possui algumas vantagens sobre o SNMPv1. São elas:
*Mais um tipo de dados: 64 bit counter;
*Melhora na eficiência e na performance: operador get-bulk;
*Notificação de evento confirmado: operador inform;
*Maior detalhamento dos erros;
*Modos facilitados de criação e deleção de linhas na MIB;
*Melhorias na definição da linguagem de dados.

Apesar do modelo SNMPv2 estar descrito no RFCs 1902-1907, alguns objetivos iniciais do projeto não foram implementados. Os objetivos não alcançados incluem o fornecimento de segurança tais como:
*autenticação: identificação da origem, integridade da mensagem;
*privacidade: confidencialidade;
*autorização e controle de acesso.

SNMPv3

Os RFCs do SNMPv3 foram produzidos pelo SNMPv3 Working Group da Internet Engineering Task Force (IETF). Esse Working Group se baseou bastante nos documentos Draft Standard do SNMPv2. Como resultado o SNMPv3 é o SNMPv2 com blocos de segurança e administração.
O modelo SNMPv3 descrito nos RFCs 2570, 2571, 2572, 2573, 2574, e 2575, relaciona as deficiências no SNMPv2 em relação a segurança e admninistração. A co-existência do SNMPv1, SNMPv2 e SNMPv3 está descrita no RFC 2576 .

Novas ferramentas foram adicionadas no SNMPv3. São elas:
*Segurança;
*autenticação e privacidade ;
*autorização e controle de acesso;
*Modelo administrativo;
*nomeação das entidades;
*gerência das chaves;
*notificação dos destinos;
*relação dos proxys configuração remota através de operadores SNMP.

Protocolo de gerenciamento SNMP

Definição

O protocolo SNMP (Simple Network Management Protocol) tem como premissa à flexibilidade e a facilidade de implementação, também em relação aos produtos futuros.
O SNMP é um protocolo de gerência definido a nível de aplicação, é utilizado para obter informações de servidores SNMP - agentes espalhados em uma rede baseada na pilha de
protocolos TCP/IP. Os dados são obtidos através de requisições de um gerente a um ou mais
agentes utilizando os serviços do protocolo de transporte UDP - User Datagram Protocol para
enviar e receber suas mensagens através da rede. Dentre as variáveis que podem ser requisitadas utilizaremos as MIBs podendo fazer parte da MIB II, da experimental ou da privada.
O gerenciamento da rede através do SNMP permite o acompanhamento simples e fácil
do estado, em tempo real, da rede, podendo ser utilizado para gerenciar diferentes tipos de sistemas.
Este gerenciamento é conhecido como modelo de gerenciamento SNMP, ou
simplesmente, gerenciamento SNMP. Portanto, o SNMP é o nome do protocolo no qual as informações são trocadas entre a MIB e a aplicação de gerência como também é o nome deste
modelo de gerência.
Os comandos são limitados e baseados no mecanismo de busca/alteração. No mecanismo de busca/alteração estão disponíveis as operações de alteração de um valor de um objeto, de obtenção dos valores de um objeto e suas variações.
A utilização de um número limitado de operações, baseadas em um mecanismo de
busca/alteração, torna o protocolo de fácil implementação, simples, estável e flexível. Como
conseqüência reduz o tráfego de mensagens de gerenciamento através da rede e permite a
introdução de novas características.
O funcionamento do SNMP é baseado em dois dispositivos o agente e o gerente. Cada
máquina gerenciada é vista como um conjunto de variáveis que representam informações referentes ao seu estado atual, estas informações ficam disponíveis ao gerente através de consulta e podem ser alteradas por ele. Cada máquina gerenciada pelo SNMP deve possuir um agente e uma base de informações MIB.

O Agente

É um processo executado na máquina gerenciada, responsável pela manutenção das
informações de gerência da máquina. As funções principais de um agente são:
* Atender as requisições enviadas pelo gerente;
*Enviar automaticamente informações de gerenciamento ao gerente, quando previamente
programado.

O agente utiliza as chamadas de sistema para realizar o monitoramento das informações
da máquina e utiliza as RPC (Remote Procedure Call) para o controle das informações da máquina.


O Gerente

É um programa executado em uma estação servidora que permite a obtenção e o envio
de informações de gerenciamento junto aos dispositivos gerenciados mediante a comunicação com um ou mais agentes.


Esta figura mostra como funciona o relacionamento de um gerente com o objeto gerenciado


O gerente fica responsável pelo monitoramento, relatórios e decisões na ocorrência de problemas enquanto que o agente fica responsável pelas funções de envio e alteração das informações e também pela notificação da ocorrência de eventos específicos ao gerente.

Esta figura mostra o relacionamento entre gerente e agente baseado no modelo TCP/IP

Serviços e Protocolos Associados às portas TCP e UDP

Na imagem abaixo listam-se os serviços e protocolos associados às portas TCP e UDP (clique na imagem para ampliar):

NCP

NCP é sigla de network control protocol, primeiro protocolo servidor a servidor da ARPANET (é a rede de compartilhamento de computadores da ARPA - Advanced Research Projects Agency, que mais tarde evoluiu para a Internet). Ele foi criado em dezembro de 1971, pelo Network Working Group (NWG).

O NCP é composto por uma família de protocolos de rede. Ele estabelece e configura os diferentes protocolos na camada de rede que serão utilizados pelo PPP.
Links ponto-a-ponto tendem a agravar alguns problemas comuns a diversas famílias de protocolos de rede. Por exemplo, atribuição e gerenciamento de endereços IP é especialmente difícil sobre circuitos comutados com links ponto-a-ponto. Estes problemas são tratados pela família de Network Control Protocols( NCPs ), onde é necessário um gerenciamento específico para cada problema.

O Protocolo PPP

O protocolo Ponto-a-Ponto (PPP (Point-to-Point Protocol)) é usado no nível da camada de enlace de dados, tendo em vista que toda a internet é baseada nele para poder fazer os equipamentos se comunicarem. E aqui não falo apenas da comunicação entre dois roteadores no meio do caminho entre seu computador e o de alguém que está no Japão. Ele trabalha também na conexão que há entre sua casa e o seu provedor de acesso à internet.
Basicamente, ele tem recursos que permitem a detecção de erros de transmissão; um subprotocolo chamado LCP (Link Control Protocol - Protocolo de Controle de Enlace) que é usado para ativar e desativar linhas de transmissão, testá-las e negociar opções de funcionamento; e um subprotocolo chamado NCP (Network Control Protocol - Protocolo de Controle de Rede) que é usado para fazer com que a camada de enlace de dados "converse" com a camada de rede.
Quanto ao NCP, existem vários tipos dele, cada um sendo usado para trabalhar em conjunto com um determinado protocolo correspondente na camada de rede.

Noção de ligação ponto a ponto

Pela linha telefônica clássica, dois computadores, no máximo, podem comunicar por modem, assim como não é possível ligar simultaneamente para duas pessoas pela mesma linha telefônica. Diz-se então que se tem uma ligação ponto a ponto, quer dizer uma ligação entre duas máquinas reduzida à sua mais simples expressão: não é preciso partilhar a linha entre várias máquinas, cada uma fala e responde por sua vez.

Assim, foram criados numerosos protocolos de modem. Os primeiros dentre eles permitiam uma simples transmissão de dados entre duas máquinas, seguidamente alguns foram dotados de um controlo de erro, e com o aumento da Internet, foram dotados da capacidade de dirigir máquinas. Desta maneira, existem doravante dois grandes protocolos de modem:
¹SLIP: um protocolo antigo, fraco em controlos
²PPP: o protocolo mais utilizado para os acessos à Internet por modem, autoriza um endereçamento das máquinas

Configurando uma rede local por shell script

Um pequeno wizard em shell script para configuração basica de uma rede local, e gerando um outro script, com o nome ecolhido pelo usuário, para iniciar a configuração posteriormente sem a nessessidade de acionar o wizard novamente.

#! /bin/bash
#*******************************************************************
#Autor: Eduardo dos Santos Monteiro
#Data: 22/04/2005
#Versão:1.0
#Cidade: Goiânia
#Estado: GO
#*******************************************************************
clear
echo "Digite o nome da Interface que deseja configurar? (Ex.: eth0)"
read INTERFACE
echo "Digite o IP Desejado (Ex.: 192.168.1.1):"
read IP
echo "Digite a Mascara (Ex.: 255.255.255.0):"
read MASCARA
echo "Digite o Gateway (Caso não tenha deixe em branco):"
read GW
echo "Digite os Servidor de DNS Primário:"
read DNS1
echo "Digite os Servidor de DNS Secundário:"
read DNS2
echo "Digite o Nome do Atalho (Ex.:"rede1". Vai ser criado um shell-script executavel na pasta /bin. Bastando apenas todas as vezes que desejar iniciar essa rede digitar o comando $rede1)"
read ATALHO
#---------------------------------------------------------------------
# VERIFICA AS CONFIGURAÇÕES APRESENTADAS
#---------------------------------------------------------------------
echo $INTERFACE
echo $IP
echo $MASCARA
echo $GW
echo $DNS1
echo $DNS2
echo /bin/$ATALHO
#Iniciando Scripts
ifconfig $INTERFACE down
ifconfig $INTERFACE $IP netmask $MASCARA up
route add default gw $GW
echo "nameserver $DNS1" > /etc/resolv.conf
echo "nameserver $DNS2" >> /etc/resolv.conf
#Criando o Script
echo "ifconfig $INTERFACE down" > /bin/$ATALHO
echo "ifconfig $INTERFACE $IP netmask $MASCARA up" >> /bin/$ATALHO
echo "route add default gw $GW" >> /bin/$ATALHO
echo "echo nameserver $DNS1 > /etc/resolv.conf" >> /bin/$ATALHO
echo "echo nameserver $DNS2 >> /etc/resolv.conf" >> /bin/$ATALHO
chmod +x /bin/$ATALHO
#---------------------------------------------------------------------
# FIM DO SCRIPT
#---------------------------------------------------------------------